From nobody Wed Oct 5 22:54:56 2016 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE10D1294AE for ; Wed, 5 Oct 2016 22:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.904 X-Spam-Level: X-Spam-Status: No, score=0.904 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.001, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, T_DKIM_INVALID=0.01, UNPARSEABLE_RELAY=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=rediffmailpro.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1No66lJiGpfJ for ; Wed, 5 Oct 2016 22:54:53 -0700 (PDT) Received: from rediffmail.com (unknown [202.137.236.157]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23B30129492 for ; Wed, 5 Oct 2016 22:54:52 -0700 (PDT) X-REDIFF-Delivered-Remotely-To: ima@ietf.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rediffmailpro.com; s=epro; t=1475733287; bh=TOtRcxcp4ghbk1MoObkHJYOoqo3MQxP29kfD1s6RGdY=; h=MIME-Version:From:Date:Message-ID:Subject:To; b=p3EoEhKlCL44IhTG7PedGU1TKjCXixLZfo7WmY/Q301P2MdZjGiOWG3EdgtEj2wws 89/bpe98Fm0Kzl3rfxzCt2FjMyfjaj9TvlYLxJJPRCit+CT0v4W2mwjMchEhQmKIkH inAlTJVWZ26cIlFLrWpTh651djOJl16YsRFFHp8w= Received: (qmail 32582 invoked by uid 510); 6 Oct 2016 05:54:47 -0000 x-m-msg: asd54ad564ad7aa6sd5as6d5; a6da7d6asas6dasd77; 5dad65ad5sd; X-OUT-VDRT-SpamState: 0\LEGIT X-OUT-VDRT-SpamScore: -100 X-OUT-VDRT-SpamCause: gggruggvucftvghtrhhoucdtuddrfeelvddrfedugddutdejucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffkgghrvfhsuffhtgesrgdtvdertddtjeenucfhrhhomhepfdfjrghrihhshhcuvehhohifughhrghrhidfuceohhgrrhhishhhsehnihigihdrihhnqeenucffohhmrghinhepihgvthhfrdhorhhgpdhfrggtvggsohhokhdrtghomhenucfkphepudeigedruddttddruddthedrudegieenucfrrghrrghmpehmohguvgepshhmthhpohhuth Date: 6 Oct 2016 05:54:47 -0000 Message-ID: <20161006055447.32573.qmail@pro-236-157.rediffmailpro.com> MIME-Version: 1.0 To: Received: from unknown 164.100.105.146 by rediffmailpro.com via HTTP; 06 Oct 2016 05:54:47 -0000 Sender: harish@nixi.in From: "Harish Chowdhary" Content-Type: multipart/alternative; boundary="=_380cb95c0824ceef97338c270cf7ab41" Archived-At: Subject: [EAI] =?utf-8?q?=5BIETF=5D_Internationalized_Email_Internet_Draft?= X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: harish@nixi.in List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 05:54:56 -0000 --=_380cb95c0824ceef97338c270cf7ab41 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Dear All,Greetings!We have just posted an INTERNET DRAFT  on deployment Issues of International Emails on IETF.https://datatracker.ietf.org/doc/draft-elkchow-iea-deploy/?include_text=1Here is a brief description of what we want to discuss during IETF 97 (Seoul,South Korea)International Email Addresses (IEA) are far from the global reality. The current de-facto language of the Internet is English.  Even today, many of the users of the Internet do not speak English as their primary language.  The next billion users of the Internet are likely to be even less familiar with English. IEA is probably the first application needed in a truly internationalized Internet.  The Email Address Internationalization (EAI) Working Group defined the RFCs to support internationalized email.  The time may now finally have come to develop best practices and to discuss the deployment challenges for IEA.Your feedback and suggestions are most welcome to make above cited draft inclusi ve of all the matters related to "Deployment of International Emails.We may further extend it to take up all the UA related issues.Hoping for your support.Thanks,Harish Chowdhary ------------------------------------------------------------------------------------------------------------------------------- [NIXI is on Social-Media too. Kindly follow us at: Facebook: https://www.facebook.com/nixiindia & Twitter: @inregistry ] This e-mail is for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies and the original message. Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this email is strictly prohibited and appropriate legal action will be taken. ------------------------------------------------------------------------------------------------- --=_380cb95c0824ceef97338c270cf7ab41 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="UTF-8" Dear All,
Greetings!

We have just posted an INTERNET DRAFT&= nbsp; on deployment Issues of International Emails on IETF.

https://datatracker.ietf.org/doc/draft-elkchow-iea-deploy/?include= _text=3D1

Here is a brief description of what we wan= t to discuss during IETF 97 (Seoul,South Korea)

Interna= tional Email Addresses (IEA) are far from the global reality. The current d= e-facto language of the Internet is English.  Even today, many of the = users of the Internet do not speak English as their primary language. = The next billion users of the Internet are likely to be even less familiar= with English. IEA is probably the first application needed in a truly inte= rnationalized Internet.  The Email Address Internationalization (EAI) = Working Group defined the RFCs to support internationalized email.  Th= e time may now finally have come to develop best practices and to discuss t= he deployment challenges for IEA.


Your feedback and sugges= tions are most welcome to make above cited draft inclusive of all the matte= rs related to "Deployment of International Emails.

We may f= urther extend it to take up all the UA related issues.

Hoping fo= r your support.

Thanks,
Harish Chowdhary

---------------------------------------------------------------------------= ----------------------------------------------------
[NIXI is on Social-= Media too. Kindly follow us at:
Facebook: https://www.facebook.com/nixii= ndia & Twitter: @inregistry ]
This e-mail is for the sole use of the int= ended recipient(s) and may
contain confidential and privileged informati= on. If you are not the
intended recipient, please contact the sender by = reply e-mail and destroy
all copies and the original message. Any unauth= orized review, use,
disclosure, dissemination, forwarding, printing or c= opying of this email
is strictly prohibited and appropriate legal action= will be taken.
--------------------------------------------------------= -----------------------------------------
--=_380cb95c0824ceef97338c270cf7ab41-- From nobody Thu Oct 6 09:39:58 2016 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16D2512971F for ; Thu, 6 Oct 2016 09:39:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1TqNO6aVDv8b for ; Thu, 6 Oct 2016 09:39:55 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 753271296F7 for ; Thu, 6 Oct 2016 09:39:55 -0700 (PDT) Received: from pps.filterd (m0053301.ppops.net [127.0.0.1]) by mx0a-00191d01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u96GZY0T042870 for ; Thu, 6 Oct 2016 12:39:55 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by mx0a-00191d01.pphosted.com with ESMTP id 25wr104xg5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 06 Oct 2016 12:39:54 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u96GdrbM015588 for ; Thu, 6 Oct 2016 12:39:53 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u96GdmYV015499 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 6 Oct 2016 12:39:52 -0400 Received: from MISOUT7MSGHUBAB.ITServices.sbc.com (MISOUT7MSGHUBAB.itservices.sbc.com [130.9.129.146]) by mlpi407.sfdc.sbc.com (RSA Interceptor) for ; Thu, 6 Oct 2016 16:39:37 GMT Received: from MISOUT7MSGUSRCG.ITServices.sbc.com ([169.254.7.8]) by MISOUT7MSGHUBAB.ITServices.sbc.com ([130.9.129.146]) with mapi id 14.03.0301.000; Thu, 6 Oct 2016 12:39:37 -0400 From: "HANSEN, TONY L" To: "ima@ietf.org" Thread-Topic: [EAI] [IETF] Internationalized Email Internet Draft Thread-Index: AQHSH/A5wCd81xRFKkifD3VhRHi+Lg== Date: Thu, 6 Oct 2016 16:39:36 +0000 Message-ID: <9EC0EB65-9C58-43ED-9A80-1DA32C58E3E0@att.com> References: <20161006055447.32573.qmail@pro-236-157.rediffmailpro.com> In-Reply-To: <20161006055447.32573.qmail@pro-236-157.rediffmailpro.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.110.198] Content-Type: multipart/alternative; boundary="_000_9EC0EB659C5843ED9A801DA32C58E3E0attcom_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-10-06_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=3 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1610060290 Archived-At: Subject: Re: [EAI] [IETF] Internationalized Email Internet Draft X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 16:39:57 -0000 --_000_9EC0EB659C5843ED9A801DA32C58E3E0attcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayBnZXR0aW5nIGRlcGxveW1lbnQgZmVlZGJhY2sgZnJvbSBFQUkgaXMgaW1wb3J0YW50 LCBhbmQgdGhpcyBkcmFmdCBpcyBhbiBleGNlbGxlbnQgc3RhcnQuDQoNCknigJltIG5vdCBjb252 aW5jZWQgdGhhdCBzZWN0aW9uIDEuMiBkZXNjcmliZXMgYSByZWFsIHByb2JsZW0uIFBlb3BsZSBk byB0aGlzIGFsbCB0aGUgdGltZSB0b2RheSB3aXRoIHZhcmlvdXMgY29tYmluYXRpb25zIG9mIGxh bmd1YWdlcy4gV2h5IGlzIHRoZSBjb21iaW5hdGlvbiBvZiBSdXNzaWFuIGFuZCBDaGluZXNlIGFu eSBkaWZmZXJlbnQ/IElmIHlvdSB0aGluayBpdCBpcywgdGhlbiBwbGVhc2UgZXhwYW5kIG9uIHRo ZSBhc3BlY3QgdGhhdCBkb2VzIG1ha2UgaXQgbW9yZSBkaWZmaWN1bHQuDQoNCkkgZm9yd2FyZGVk IGEgbnVtYmVyIG9mIG5pdHMgdG8gdGhlIGF1dGhvcnMuDQoNCiAgICAgICAgICAgICAgICBUb255 IEhhbnNlbg0KDQpGcm9tOiBJTUEgPGltYS1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2Yg SGFyaXNoIENob3dkaGFyeSA8aGFyaXNoQG5peGkuaW4+DQpSZXBseS1UbzogImhhcmlzaEBuaXhp LmluIiA8aGFyaXNoQG5peGkuaW4+DQpEYXRlOiBUaHVyc2RheSwgT2N0b2JlciA2LCAyMDE2IGF0 IDE6NTQgQU0NClRvOiAiaW1hQGlldGYub3JnIiA8aW1hQGlldGYub3JnPg0KU3ViamVjdDogW0VB SV0gW0lFVEZdIEludGVybmF0aW9uYWxpemVkIEVtYWlsIEludGVybmV0IERyYWZ0DQoNCkRlYXIg QWxsLA0KR3JlZXRpbmdzIQ0KDQpXZSBoYXZlIGp1c3QgcG9zdGVkIGFuIElOVEVSTkVUIERSQUZU ICBvbiBkZXBsb3ltZW50IElzc3VlcyBvZiBJbnRlcm5hdGlvbmFsIEVtYWlscyBvbiBJRVRGLg0K DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1lbGtjaG93LWllYS1kZXBs b3kvP2luY2x1ZGVfdGV4dD0xDQoNCkhlcmUgaXMgYSBicmllZiBkZXNjcmlwdGlvbiBvZiB3aGF0 IHdlIHdhbnQgdG8gZGlzY3VzcyBkdXJpbmcgSUVURiA5NyAoU2VvdWwsU291dGggS29yZWEpDQoN CkludGVybmF0aW9uYWwgRW1haWwgQWRkcmVzc2VzIChJRUEpIGFyZSBmYXIgZnJvbSB0aGUgZ2xv YmFsIHJlYWxpdHkuIFRoZSBjdXJyZW50IGRlLWZhY3RvIGxhbmd1YWdlIG9mIHRoZSBJbnRlcm5l dCBpcyBFbmdsaXNoLiAgRXZlbiB0b2RheSwgbWFueSBvZiB0aGUgdXNlcnMgb2YgdGhlIEludGVy bmV0IGRvIG5vdCBzcGVhayBFbmdsaXNoIGFzIHRoZWlyIHByaW1hcnkgbGFuZ3VhZ2UuICBUaGUg bmV4dCBiaWxsaW9uIHVzZXJzIG9mIHRoZSBJbnRlcm5ldCBhcmUgbGlrZWx5IHRvIGJlIGV2ZW4g bGVzcyBmYW1pbGlhciB3aXRoIEVuZ2xpc2guIElFQSBpcyBwcm9iYWJseSB0aGUgZmlyc3QgYXBw bGljYXRpb24gbmVlZGVkIGluIGEgdHJ1bHkgaW50ZXJuYXRpb25hbGl6ZWQgSW50ZXJuZXQuICBU aGUgRW1haWwgQWRkcmVzcyBJbnRlcm5hdGlvbmFsaXphdGlvbiAoRUFJKSBXb3JraW5nIEdyb3Vw IGRlZmluZWQgdGhlIFJGQ3MgdG8gc3VwcG9ydCBpbnRlcm5hdGlvbmFsaXplZCBlbWFpbC4gIFRo ZSB0aW1lIG1heSBub3cgZmluYWxseSBoYXZlIGNvbWUgdG8gZGV2ZWxvcCBiZXN0IHByYWN0aWNl cyBhbmQgdG8gZGlzY3VzcyB0aGUgZGVwbG95bWVudCBjaGFsbGVuZ2VzIGZvciBJRUEuDQoNCg0K WW91ciBmZWVkYmFjayBhbmQgc3VnZ2VzdGlvbnMgYXJlIG1vc3Qgd2VsY29tZSB0byBtYWtlIGFi b3ZlIGNpdGVkIGRyYWZ0IGluY2x1c2l2ZSBvZiBhbGwgdGhlIG1hdHRlcnMgcmVsYXRlZCB0byAi RGVwbG95bWVudCBvZiBJbnRlcm5hdGlvbmFsIEVtYWlscy4NCg0KV2UgbWF5IGZ1cnRoZXIgZXh0 ZW5kIGl0IHRvIHRha2UgdXAgYWxsIHRoZSBVQSByZWxhdGVkIGlzc3Vlcy4NCg0KSG9waW5nIGZv ciB5b3VyIHN1cHBvcnQuDQoNClRoYW5rcywNCkhhcmlzaCBDaG93ZGhhcnkNCg0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KW05JWEkgaXMgb24gU29jaWFsLU1lZGlhIHRvby4gS2luZGx5IGZvbGxvdyB1cyBhdDoN CkZhY2Vib29rOiBodHRwczovL3d3dy5mYWNlYm9vay5jb20vbml4aWluZGlhICYgVHdpdHRlcjog QGlucmVnaXN0cnkgXQ0KVGhpcyBlLW1haWwgaXMgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50 ZW5kZWQgcmVjaXBpZW50KHMpIGFuZCBtYXkNCmNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2 aWxlZ2VkIGluZm9ybWF0aW9uLiBJZiB5b3UgYXJlIG5vdCB0aGUNCmludGVuZGVkIHJlY2lwaWVu dCwgcGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBieSByZXBseSBlLW1haWwgYW5kIGRlc3Ryb3kN CmFsbCBjb3BpZXMgYW5kIHRoZSBvcmlnaW5hbCBtZXNzYWdlLiBBbnkgdW5hdXRob3JpemVkIHJl dmlldywgdXNlLA0KZGlzY2xvc3VyZSwgZGlzc2VtaW5hdGlvbiwgZm9yd2FyZGluZywgcHJpbnRp bmcgb3IgY29weWluZyBvZiB0aGlzIGVtYWlsDQppcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBh cHByb3ByaWF0ZSBsZWdhbCBhY3Rpb24gd2lsbCBiZSB0YWtlbi4NCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0K --_000_9EC0EB659C5843ED9A801DA32C58E3E0attcom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiSGVsdmV0aWNhIE5ldWUiOw0KCXBhbm9zZS0xOjIgMCA1IDMgMCAwIDAgMiAwIDQ7fQ0KLyog U3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29O b3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4u TXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0Zv bGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOndpbmRvd3Rl eHQ7fQ0Kc3Bhbi5tc29JbnMNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLXN0 eWxlLW5hbWU6IiI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTsNCgljb2xvcjp0ZWFsO30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1h cmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0 ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWF1dG9zcGFj ZTpub25lIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJp Ij5JIHRoaW5rIGdldHRpbmcgZGVwbG95bWVudCBmZWVkYmFjayBmcm9tIEVBSSBpcyBpbXBvcnRh bnQsIGFuZCB0aGlzIGRyYWZ0IGlzIGFuIGV4Y2VsbGVudCBzdGFydC48L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7Ij48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hdXRvc3BhY2U6bm9u ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5i c3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZx dW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 InRleHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OkNhbGlicmkiPknigJltIG5vdCBjb252aW5jZWQgdGhhdCBzZWN0aW9uIDEuMiBkZXNj cmliZXMgYSByZWFsIHByb2JsZW0uIFBlb3BsZSBkbyB0aGlzIGFsbCB0aGUgdGltZSB0b2RheSB3 aXRoIHZhcmlvdXMgY29tYmluYXRpb25zIG9mIGxhbmd1YWdlcy4gV2h5IGlzIHRoZSBjb21iaW5h dGlvbg0KIG9mIFJ1c3NpYW4gYW5kIENoaW5lc2UgYW55IGRpZmZlcmVudD8gSWYgeW91IHRoaW5r IGl0IGlzLCB0aGVuIHBsZWFzZSBleHBhbmQgb24gdGhlIGFzcGVjdCB0aGF0IGRvZXMgbWFrZSBp dCBtb3JlIGRpZmZpY3VsdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0idGV4dC1hdXRvc3BhY2U6bm9uZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPkkgZm9yd2FyZGVkIGEg bnVtYmVyIG9mIG5pdHMgdG8gdGhlIGF1dGhvcnMuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJy aSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRvbnkgSGFuc2VuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj4N CjwvYj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFjayI+SU1BICZs dDtpbWEtYm91bmNlc0BpZXRmLm9yZyZndDsgb24gYmVoYWxmIG9mIEhhcmlzaCBDaG93ZGhhcnkg Jmx0O2hhcmlzaEBuaXhpLmluJmd0Ozxicj4NCjxiPlJlcGx5LVRvOiA8L2I+JnF1b3Q7aGFyaXNo QG5peGkuaW4mcXVvdDsgJmx0O2hhcmlzaEBuaXhpLmluJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5U aHVyc2RheSwgT2N0b2JlciA2LCAyMDE2IGF0IDE6NTQgQU08YnI+DQo8Yj5UbzogPC9iPiZxdW90 O2ltYUBpZXRmLm9yZyZxdW90OyAmbHQ7aW1hQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6 IDwvYj5bRUFJXSBbSUVURl0gSW50ZXJuYXRpb25hbGl6ZWQgRW1haWwgSW50ZXJuZXQgRHJhZnQ8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RGVh ciBBbGwsPGJyPg0KR3JlZXRpbmdzITxicj4NCjxicj4NCldlIGhhdmUganVzdCBwb3N0ZWQgYW4g SU5URVJORVQgRFJBRlQmbmJzcDsgb24gZGVwbG95bWVudCBJc3N1ZXMgb2YgSW50ZXJuYXRpb25h bCBFbWFpbHMgb24gSUVURi48YnI+DQo8YnI+DQo8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1lbGtjaG93LWllYS1kZXBsb3kvP2luY2x1ZGVfdGV4dD0xIj5o dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1lbGtjaG93LWllYS1kZXBsb3kv P2luY2x1ZGVfdGV4dD0xPC9hPjxicj4NCjxicj4NCjxzdHJvbmc+SGVyZSBpcyBhIGJyaWVmIGRl c2NyaXB0aW9uIG9mIHdoYXQgd2Ugd2FudCB0byBkaXNjdXNzIGR1cmluZyBJRVRGIDk3IChTZW91 bCxTb3V0aCBLb3JlYSk8L3N0cm9uZz48YnI+DQo8YnI+DQpJbnRlcm5hdGlvbmFsIEVtYWlsIEFk ZHJlc3NlcyAoSUVBKSBhcmUgZmFyIGZyb20gdGhlIGdsb2JhbCByZWFsaXR5LiBUaGUgY3VycmVu dCBkZS1mYWN0byBsYW5ndWFnZSBvZiB0aGUgSW50ZXJuZXQgaXMgRW5nbGlzaC4mbmJzcDsgRXZl biB0b2RheSwgbWFueSBvZiB0aGUgdXNlcnMgb2YgdGhlIEludGVybmV0IGRvIG5vdCBzcGVhayBF bmdsaXNoIGFzIHRoZWlyIHByaW1hcnkgbGFuZ3VhZ2UuJm5ic3A7IFRoZSBuZXh0IGJpbGxpb24g dXNlcnMgb2YgdGhlIEludGVybmV0DQogYXJlIGxpa2VseSB0byBiZSBldmVuIGxlc3MgZmFtaWxp YXIgd2l0aCBFbmdsaXNoLiBJRUEgaXMgcHJvYmFibHkgdGhlIGZpcnN0IGFwcGxpY2F0aW9uIG5l ZWRlZCBpbiBhIHRydWx5IGludGVybmF0aW9uYWxpemVkIEludGVybmV0LiZuYnNwOyBUaGUgRW1h aWwgQWRkcmVzcyBJbnRlcm5hdGlvbmFsaXphdGlvbiAoRUFJKSBXb3JraW5nIEdyb3VwIGRlZmlu ZWQgdGhlIFJGQ3MgdG8gc3VwcG9ydCBpbnRlcm5hdGlvbmFsaXplZCBlbWFpbC4mbmJzcDsgVGhl IHRpbWUNCiBtYXkgbm93IGZpbmFsbHkgaGF2ZSBjb21lIHRvIGRldmVsb3AgYmVzdCBwcmFjdGlj ZXMgYW5kIHRvIGRpc2N1c3MgdGhlIGRlcGxveW1lbnQgY2hhbGxlbmdlcyBmb3IgSUVBLjxicj4N Cjxicj4NCjxicj4NCllvdXIgZmVlZGJhY2sgYW5kIHN1Z2dlc3Rpb25zIGFyZSBtb3N0IHdlbGNv bWUgdG8gbWFrZSBhYm92ZSBjaXRlZCBkcmFmdCBpbmNsdXNpdmUgb2YgYWxsIHRoZSBtYXR0ZXJz IHJlbGF0ZWQgdG8gJnF1b3Q7RGVwbG95bWVudCBvZiBJbnRlcm5hdGlvbmFsIEVtYWlscy48YnI+ DQo8YnI+DQpXZSBtYXkgZnVydGhlciBleHRlbmQgaXQgdG8gdGFrZSB1cCBhbGwgdGhlIFVBIHJl bGF0ZWQgaXNzdWVzLjxicj4NCjxicj4NCkhvcGluZyBmb3IgeW91ciBzdXBwb3J0Ljxicj4NCjxi cj4NClRoYW5rcyw8YnI+DQpIYXJpc2ggQ2hvd2RoYXJ5PGJyPg0KPGJyPg0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LTxicj4NCltOSVhJIGlzIG9uIFNvY2lhbC1NZWRpYSB0b28uIEtpbmRseSBmb2xsb3cgdXMgYXQ6 PGJyPg0KRmFjZWJvb2s6IGh0dHBzOi8vd3d3LmZhY2Vib29rLmNvbS9uaXhpaW5kaWEgJmFtcDsg VHdpdHRlcjogQGlucmVnaXN0cnkgXTxicj4NClRoaXMgZS1tYWlsIGlzIGZvciB0aGUgc29sZSB1 c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKSBhbmQgbWF5PGJyPg0KY29udGFpbiBjb25m aWRlbnRpYWwgYW5kIHByaXZpbGVnZWQgaW5mb3JtYXRpb24uIElmIHlvdSBhcmUgbm90IHRoZTxi cj4NCmludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBieSByZXBs eSBlLW1haWwgYW5kIGRlc3Ryb3k8YnI+DQphbGwgY29waWVzIGFuZCB0aGUgb3JpZ2luYWwgbWVz c2FnZS4gQW55IHVuYXV0aG9yaXplZCByZXZpZXcsIHVzZSw8YnI+DQpkaXNjbG9zdXJlLCBkaXNz ZW1pbmF0aW9uLCBmb3J3YXJkaW5nLCBwcmludGluZyBvciBjb3B5aW5nIG9mIHRoaXMgZW1haWw8 YnI+DQppcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBhcHByb3ByaWF0ZSBsZWdhbCBhY3Rpb24g d2lsbCBiZSB0YWtlbi48YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_9EC0EB659C5843ED9A801DA32C58E3E0attcom_-- From nobody Sun Oct 9 19:58:01 2016 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8F7A129465 for ; Sun, 9 Oct 2016 19:57:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gtoo2OxwjQwt for ; Sun, 9 Oct 2016 19:57:58 -0700 (PDT) Received: from bsa3.jck.com (static-65-175-133-137.cpe.metrocast.net [65.175.133.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41FF4129409 for ; Sun, 9 Oct 2016 19:57:57 -0700 (PDT) Received: from hp5.int.jck.com ([198.252.137.153] helo=JcK-HP5.jck.com) by bsa3.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1btQmn-0004TC-Gr; Sun, 09 Oct 2016 22:57:53 -0400 Date: Sun, 09 Oct 2016 22:57:48 -0400 From: John C Klensin To: "HANSEN, TONY L" , ima@ietf.org Message-ID: In-Reply-To: <9EC0EB65-9C58-43ED-9A80-1DA32C58E3E0@att.com> References: <20161006055447.32573.qmail@pro-236-157.rediffmailpro.com> <9EC0EB65-9C58-43ED-9A80-1DA32C58E3E0@att.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Archived-At: Subject: Re: [EAI] [IETF] Internationalized Email Internet Draft X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2016 02:58:00 -0000 --On Thursday, October 06, 2016 4:39 PM +0000 "HANSEN, TONY L" wrote: > I think getting deployment feedback from EAI is important, and > this draft is an excellent start. >=20 > I'm not convinced that section 1.2 describes a real problem. > People do this all the time today with various combinations of > languages. Why is the combination of Russian and Chinese any > different? If you think it is, then please expand on the > aspect that does make it more difficult. >=20 > I forwarded a number of nits to the authors. Hi. I was going to hold off until some later and more mature version of this draft, but since Tony has commented, while I believe the issues with EAI deployment are important, I see several problems with this draft, some of which were actually discussed in the WG but appear to be ignored here. Perhaps more important, it is seriously incomplete relative to issues that have been discussed at great length in the EAI WG, at the APEC meeting on internationalized email in Beijing in October 2014, the May 2015 workshop in Thailand, and elsewhere. I strongly suggest that, if there is going to be a discussion in Seoul, this document is in need of a great deal of work first. Some of those issues are: (1) The so-called EAI standards, as listed in the Introduction, are about email envelope and header information presented directly (e.g., in UTF-8) as non-ASCII characters. A good deal of the document appears to address mail content information such as textual message bodies, in other scripts. With the possible exception of language selection when a message is sent with the same basic text in several languages (multipart/alternative was designed with that case in mind but have been used in other ways), we thought we solved that content problem with MIME in 1992. If MIME is inadequate, the authors or others should produce a document explaining the issues and not confuse them with EAI / SMTPUTF8. If it is adequate, then, like Tony although perhaps for different reasons, I don't see what Section 1.2 is doing here, what the relevance of Section 3.2 is, and several other statements should be examined carefully to be sure they are talking about addresses and/or headers and not content. (2) Within an address, there is, as the I-D points out and consistent with RFC 5321, a local part and a domain part. RFCs 6530 and 6531 make it quite clear (at least we thought they did) that they are handled differently. For the domain part, the rules are laid out in the IDNA2008 specs (RFC 5890ff). Issues about look-alike characters have been extensively discussed and written about (even though some of us have questioned the quality of some of that work). It does not seem useful to me to revisit those issues here, especially without reference to the prior work and discussions or if some of the discussion here is wrong or contains obvious omissions. As an example from the first paragraph of Section 6.1, Latin "c" (U+0063) and Cyrillic "c" (U+0441) are typically written with identical graphemes, but are not on the list. More important, while the "paypal" example with U+0430 substituted for "a" (U+0061) has been used repeatedly, including in a careful study in an article that is not cited in this draft, it is possible to write = "=D1=80=D0=B0=D1=83=D1=80=D0=B01" with the first five characters in Cyrillic and the last one a digit (which is script independent) (\u'0440'\u'0430'\u'0443'\u'0440'\u'040'\u'0031' [1]), therefore not even violating conventions prohibiting mixed-script labels. There is, of course, no ambiguity in the A-label form, although the authors quite properly point out that it is not user-friendly. By contrast, Section 1.1 talks about display of email addresses, including the local part ("in Punycode" [2]). While a mail delivery server is free to create whatever aliases for a mailbox local part it likes, including "xn-t2bmh3a" or "123456", "george" or "example", in general converting a local part using the Punycode algorithm and displaying the result is prohibited by the EAI standards (and, incidentally, RFC5321). More important, it will often lose information and is potentially very dangerous. (3) Arabic should not be confused with a strictly right-to-left writing system. I am not aware of any such systems in wide use for contemporary languages today. The problem is that numerals, whether written in European digits, Arabic or Arabic-Indic digits, Chinese (Han) digits, or many others, have been written left to right since that type of positional notation was invented and became widely used. As a result, the scripts are referred to (in Unicode-speak) as "bidirectional" or "bidi" [3]. Their implications for domain names and IDNA are the subject of RFC 5893. (4) Multiple addresses for one user (and Section 4). Keeping in mind that many people maintain a number of identities, and even multiple email addresses, for different purposes, I don't understand what point you are trying to make with this section. Many of us believe that users who have mailboxes whose names involve non-ASCII local parts and who engage in communications outside their primary language group will find it necessary to maintain either separate all-ASCII mailboxes or all-ASCII aliases to their primary mailboxes and to do so for a very long time. That issue has been extensively analyzed and discussed but this document avoids that work, which is both a problem and an opportunity. (5) Section 2.1 asserts that email servers), implying all of them, store data (messages?) in relational databases. That is simply false. Some do; others don't. Even for those that do, there may be a difference between Unicode-capable data storage and Unicode-capable keys or indexes. There is also absolutely no requirement that any such system store Unicode strings encoded in UTF-8; many do not. =20 (6) There is a necessary difficulty with SMTPUTF8, which is that one cannot transmit a message with non-ASCII characters in addresses or headers to a system that does not support them. Final delivery systems should probably not accept messages unless they have reason to predict that the mail store will handle them _and_ that the user associated with the target mailbox will be able to retrieve them. Since a user with an all-ASCII mailbox name might still receive a message with, e.g., a non-ASCII backward-pointing address in the envelope or headers, making that decision is not straightforward. That leads to a strong case that, if one wants broad deployment of SMTPUTF8, the place to start is with the MUAs (including the Webmail systems) and associated POP and IMAP servers and clients. The "to various extents" list in the first part of Section 3 is not particularly helpful in that regard. (7) Finally, this is an internationalization (i18n) problem as much as it is an email problem. Terminology (and, where characters or code points are referred to, their precise identification) is very important because the alternative is typically a good deal of user confusion about what you are talking about and other impediments to making progress. Saying "English" were you mean "Basic Latin Script" or "ASCII" is not helpful, especially given that 5321 local parts can include any ASCII character and that ASCII is not sufficient to write English. Conversely, it appears that there are a few places where, correctly or incorrectly, you really do mean "English" when you say that. Similarly, talking about one particular encoding when you mean "Unicode" is confusing and may be misleading. RFC 6365 may give you a start on some of the = issues. regards, john ------------- [1] I recommend the authors have a look at RFC 5137. [2] Punycode is an encoding method, not a display format. See RFC 5890, Section 2.3.4.=20 [3] http://unicode.org/reports/tr9/ From nobody Mon Oct 10 07:25:49 2016 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84864129533 for ; Mon, 10 Oct 2016 07:25:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N2uuyrZEyAhI for ; Mon, 10 Oct 2016 07:25:43 -0700 (PDT) Received: from nm10-vm5.bullet.mail.ne1.yahoo.com (nm10-vm5.bullet.mail.ne1.yahoo.com [98.138.91.232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CD6112948D for ; Mon, 10 Oct 2016 07:25:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1476109542; bh=SnSP0SJDyucdpZZl78+zcNk2ivN9EROJrUTCYEE4Y20=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=ud7r98nSVnS09rLPqTGJBMSc2BRsRZXIiPfcNTwggWw33lFPLNimIREczXD6kNJDlcTLFddOUfXm39tnXVkyhhFKE7DOMsRbCqa8QkXeJ70jFey5r0VYlu5lUmdJBcjULgozQhvv6smxn607GUAfJThFtXYTNAF1buHDUwblcJVxwmNrGMsNQUdLer/DiUdHmFJErKd10RkLxolW51MJ6ul3MSdcC+co9DIcXm4fbOGTUycVpcJx4L+wtzrmfWe4MD3Sp2o5gMe0htXNfw+znBP79IzfHjVaLfbNA90A3RiGPKj5LJx82+9TaYU4ZsqiV71JaxboMQdp3HRqWcOK1Q== Received: from [98.138.101.132] by nm10.bullet.mail.ne1.yahoo.com with NNFMP; 10 Oct 2016 14:25:42 -0000 Received: from [98.138.226.169] by tm20.bullet.mail.ne1.yahoo.com with NNFMP; 10 Oct 2016 14:25:42 -0000 Received: from [127.0.0.1] by omp1070.mail.ne1.yahoo.com with NNFMP; 10 Oct 2016 14:25:42 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 640156.7438.bm@omp1070.mail.ne1.yahoo.com X-YMail-OSG: vXr0u0AVM1mPmhv1L336u_V3bA3KKQA9ex.NphoObmXOx8hLZp5MFBRONG.MEcf Rw18RhcVE6FnnSWR8SuVBx6EGUztSBXjZjUQBAZ9QB7BFmRfS_dmViPcuVE4zUmrsybLWBBIGdOl sCQPJSLr3toDd2IsmW8x9DDM_mb9wZkGtBjt.rT8f2LQJ7VugjujWt_1U_abf3hb7kIlv_XxmTCN RX32hy1hDC3tPpZlM_T7VzjBhI.wF2slz6T385Iy.2Yq24zJVSAh0GtAHkf1xLh3sfR1nEelHjJb VQKl3p_AxHmpF3fyaBH7V7TudQqh3jfxyAf88U_Hr_Yg7bxsGqHMDS8YHPxLlX8VeFdHK2tISfqz cN5KhIxHsmsbUkLKHAZuWhpAjOMTrSjYewo4CEgKE1ZIPyDAFGoM6O_BFdwCZGtz.TzGd1627XaD pJKKFRylPI5gNvUpdW1e0mGb.UhAJC.bK7M1MdjLpIMT66xtQZ2yHCJ0TUed46KDL1HV2AOUVLjg DZKwnyzkitimOFwJ8cEYlohGznwgGsFXaBp_FV3Eu.KhghaTOU.c- Received: from jws100136.mail.ne1.yahoo.com by sendmailws123.mail.ne1.yahoo.com; Mon, 10 Oct 2016 14:25:42 +0000; 1476109542.026 Date: Mon, 10 Oct 2016 14:25:40 +0000 (UTC) From: To: John C Klensin , "HANSEN, TONY L" , "ima@ietf.org" Message-ID: <1194474350.1204941.1476109540850@mail.yahoo.com> In-Reply-To: References: <20161006055447.32573.qmail@pro-236-157.rediffmailpro.com> <9EC0EB65-9C58-43ED-9A80-1DA32C58E3E0@att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [EAI] [IETF] Internationalized Email Internet Draft X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: nalini.elkins@insidethestack.com List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2016 14:25:48 -0000 John, Thanks so much for taking so much time to think about this issue and how to= set a solid foundation. Please bear with us as we are trying to catch up with the work that has bee= n done by the WG and others. Let us think over your comments and then I think we will start a separate t= hread for each comment. Let me read and think quietly over what you have s= aid before I reply to the comments. =20 Nalini Elkins Inside Products, Inc. www.insidethestack.com (831) 659-8360 ----- Original Message ----- From: John C Klensin To: "HANSEN, TONY L" ; ima@ietf.org Sent: Sunday, October 9, 2016 7:57 PM Subject: Re: [EAI] [IETF] Internationalized Email Internet Draft --On Thursday, October 06, 2016 4:39 PM +0000 "HANSEN, TONY L" wrote: > I think getting deployment feedback from EAI is important, and > this draft is an excellent start. >=20 > I'm not convinced that section 1.2 describes a real problem. > People do this all the time today with various combinations of > languages. Why is the combination of Russian and Chinese any > different? If you think it is, then please expand on the > aspect that does make it more difficult. >=20 > I forwarded a number of nits to the authors. Hi. I was going to hold off until some later and more mature version of this draft, but since Tony has commented, while I believe the issues with EAI deployment are important, I see several problems with this draft, some of which were actually discussed in the WG but appear to be ignored here. Perhaps more important, it is seriously incomplete relative to issues that have been discussed at great length in the EAI WG, at the APEC meeting on internationalized email in Beijing in October 2014, the May 2015 workshop in Thailand, and elsewhere. I strongly suggest that, if there is going to be a discussion in Seoul, this document is in need of a great deal of work first. Some of those issues are: (1) The so-called EAI standards, as listed in the Introduction, are about email envelope and header information presented directly (e.g., in UTF-8) as non-ASCII characters. A good deal of the document appears to address mail content information such as textual message bodies, in other scripts. With the possible exception of language selection when a message is sent with the same basic text in several languages (multipart/alternative was designed with that case in mind but have been used in other ways), we thought we solved that content problem with MIME in 1992. If MIME is inadequate, the authors or others should produce a document explaining the issues and not confuse them with EAI / SMTPUTF8. If it is adequate, then, like Tony although perhaps for different reasons, I don't see what Section 1.2 is doing here, what the relevance of Section 3.2 is, and several other statements should be examined carefully to be sure they are talking about addresses and/or headers and not content. (2) Within an address, there is, as the I-D points out and consistent with RFC 5321, a local part and a domain part. RFCs 6530 and 6531 make it quite clear (at least we thought they did) that they are handled differently. For the domain part, the rules are laid out in the IDNA2008 specs (RFC 5890ff). Issues about look-alike characters have been extensively discussed and written about (even though some of us have questioned the quality of some of that work). It does not seem useful to me to revisit those issues here, especially without reference to the prior work and discussions or if some of the discussion here is wrong or contains obvious omissions. As an example from the first paragraph of Section 6.1, Latin "c" (U+0063) and Cyrillic "c" (U+0441) are typically written with identical graphemes, but are not on the list. More important, while the "paypal" example with U+0430 substituted for "a" (U+0061) has been used repeatedly, including in a careful study in an article that is not cited in this draft, it is possible to write "=D1=80=D0=B0=D1=83=D1=80= =D0=B01" with the first five characters in Cyrillic and the last one a digit (which is script independent) (\u'0440'\u'0430'\u'0443'\u'0440'\u'040'\u'0031' [1]), therefore not even violating conventions prohibiting mixed-script labels. There is, of course, no ambiguity in the A-label form, although the authors quite properly point out that it is not user-friendly. By contrast, Section 1.1 talks about display of email addresses, including the local part ("in Punycode" [2]). While a mail delivery server is free to create whatever aliases for a mailbox local part it likes, including "xn-t2bmh3a" or "123456", "george" or "example", in general converting a local part using the Punycode algorithm and displaying the result is prohibited by the EAI standards (and, incidentally, RFC5321). More important, it will often lose information and is potentially very dangerous. (3) Arabic should not be confused with a strictly right-to-left writing system. I am not aware of any such systems in wide use for contemporary languages today. The problem is that numerals, whether written in European digits, Arabic or Arabic-Indic digits, Chinese (Han) digits, or many others, have been written left to right since that type of positional notation was invented and became widely used. As a result, the scripts are referred to (in Unicode-speak) as "bidirectional" or "bidi" [3]. Their implications for domain names and IDNA are the subject of RFC 5893. (4) Multiple addresses for one user (and Section 4). Keeping in mind that many people maintain a number of identities, and even multiple email addresses, for different purposes, I don't understand what point you are trying to make with this section. Many of us believe that users who have mailboxes whose names involve non-ASCII local parts and who engage in communications outside their primary language group will find it necessary to maintain either separate all-ASCII mailboxes or all-ASCII aliases to their primary mailboxes and to do so for a very long time. That issue has been extensively analyzed and discussed but this document avoids that work, which is both a problem and an opportunity. (5) Section 2.1 asserts that email servers), implying all of them, store data (messages?) in relational databases. That is simply false. Some do; others don't. Even for those that do, there may be a difference between Unicode-capable data storage and Unicode-capable keys or indexes. There is also absolutely no requirement that any such system store Unicode strings encoded in UTF-8; many do not. =20 (6) There is a necessary difficulty with SMTPUTF8, which is that one cannot transmit a message with non-ASCII characters in addresses or headers to a system that does not support them. Final delivery systems should probably not accept messages unless they have reason to predict that the mail store will handle them _and_ that the user associated with the target mailbox will be able to retrieve them. Since a user with an all-ASCII mailbox name might still receive a message with, e.g., a non-ASCII backward-pointing address in the envelope or headers, making that decision is not straightforward. That leads to a strong case that, if one wants broad deployment of SMTPUTF8, the place to start is with the MUAs (including the Webmail systems) and associated POP and IMAP servers and clients. The "to various extents" list in the first part of Section 3 is not particularly helpful in that regard. (7) Finally, this is an internationalization (i18n) problem as much as it is an email problem. Terminology (and, where characters or code points are referred to, their precise identification) is very important because the alternative is typically a good deal of user confusion about what you are talking about and other impediments to making progress. Saying "English" were you mean "Basic Latin Script" or "ASCII" is not helpful, especially given that 5321 local parts can include any ASCII character and that ASCII is not sufficient to write English. Conversely, it appears that there are a few places where, correctly or incorrectly, you really do mean "English" when you say that. Similarly, talking about one particular encoding when you mean "Unicode" is confusing and may be misleading. RFC 6365 may give you a start on some of the issues. regards, john ------------- [1] I recommend the authors have a look at RFC 5137. [2] Punycode is an encoding method, not a display format. See RFC 5890, Section 2.3.4.=20 [3] http://unicode.org/reports/tr9/ _______________________________________________ IMA mailing list IMA@ietf.org https://www.ietf.org/mailman/listinfo/ima From nobody Fri Oct 14 06:30:56 2016 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B80DF1294F2 for ; Fri, 14 Oct 2016 06:30:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o731kysiCJxx for ; Fri, 14 Oct 2016 06:30:51 -0700 (PDT) Received: from nm23-vm0.bullet.mail.ne1.yahoo.com (nm23-vm0.bullet.mail.ne1.yahoo.com [98.138.91.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 953721294E7 for ; Fri, 14 Oct 2016 06:30:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1476451850; bh=cW2FbQ7BXfQSnSz2IgeWYPSo/k2ftRAtBJeaMJa2oFc=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=LBeiORySZ/fzmF55lD/kt6bwV7vcQ3e21UA6Ct3EXd5V5JZVZ9wIa+ZvO8v/NawoLAMsmYv/reKn5QlvK5S0iP9Rnkgatd55jun9DoaO+oGYhPbbVRUQXEDyL0Mc9XdtAej9Ycn8K9cCl2KnKDWyJEIQtGfWuZFIqUdbyYKmMomYK3AQef49ozmSqXLnEpFr4EmncLPJvGLGk8XCD5+qcq30niILlWbp5LAVWHKngpCJyK19MJIcp6b2ju78HHYB6xwA5wbHzDyOHYsQxXbHBvSofblanBVRb42dVSTXetYbKwbxX0w7KxZ03R7jjRhZcIlAhHaUQ56ZM/C/2XzWUQ== Received: from [98.138.100.113] by nm23.bullet.mail.ne1.yahoo.com with NNFMP; 14 Oct 2016 13:30:50 -0000 Received: from [98.138.89.232] by tm104.bullet.mail.ne1.yahoo.com with NNFMP; 14 Oct 2016 13:30:50 -0000 Received: from [127.0.0.1] by omp1047.mail.ne1.yahoo.com with NNFMP; 14 Oct 2016 13:30:50 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 34070.9218.bm@omp1047.mail.ne1.yahoo.com X-YMail-OSG: DpYJt7IVM1leq00MBBx0gNq6DsEnvXq33yWxExXUQqcvhpPCKPpsVYOM0lFXnV3 uMl0B6ax_LbVGeXVRboe48tPjfIkOrY9oOXLMXEafrcpdlvAdeboPv_Mo4ojfG22IrcThmqwv6Px pmO7W2tF_ASLapn1g9KlpheT505gIO5JgjnjEQzNAi.5k43DeiiMw0hXSzdHekQS1TOqqSE6.knx qIq_.IhRP.0SoAvhfDSF2z0aAxPRvdK2jRZhIiJGa_AtWuhIrWO_Xv7_qQqvj83XbEudpSjJiVc7 xCbIL.s85o6C5URkXMsFsIlMRW7L74CVXYr.4M7EwvXVVG3eIiIJSBYHF5ig0H9MSp3KbDPHvzy1 sFHqZsIZvLFXUB2YmQ8i4IQHRce4eNX3iVq5a_PyYRbX7I.UMOAbQEKMeiof_BkY9MeR4V8INCuj OTObW78svMqhZ0lQFdIYRwS12pO7p0H_CdTuvQ0r7_Q9HkiRTsG_I4y5WhpooFqNx1_64oxUjeVZ 4jIRRu3exBiF.eYFECIwbn2ScGGKmog60SUrDuw3QxUFKVTn5e2U- Received: from jws200064.mail.ne1.yahoo.com by sendmailws118.mail.ne1.yahoo.com; Fri, 14 Oct 2016 13:30:49 +0000; 1476451849.644 Date: Fri, 14 Oct 2016 13:30:36 +0000 (UTC) From: To: John C Klensin , "HANSEN, TONY L" , "ima@ietf.org" Message-ID: <489025644.216489.1476451836537@mail.yahoo.com> In-Reply-To: References: <20161006055447.32573.qmail@pro-236-157.rediffmailpro.com> <9EC0EB65-9C58-43ED-9A80-1DA32C58E3E0@att.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_216488_699762746.1476451836529" Archived-At: Cc: Harish Chowdhary Subject: [EAI] [IETF] Content Issues [ was: Internationalized Email Internet Draft] X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: nalini.elkins@insidethestack.com List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 13:30:55 -0000 ------=_Part_216488_699762746.1476451836529 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable John / Tony, I am going to split your comments into separate threads so that I can keep = track of each. =C2=A0 The first is about co-mingling content vs. headers. >(1) The so-called EAI standards, as listed in the Introduction,=C2=A0are a= bout email envelope and header information presented=C2=A0directly (e.g., i= n UTF-8) as non-ASCII characters.=C2=A0 A good deal=C2=A0of the document ap= pears to address mail >content information such=C2=A0as textual message bod= ies, in other scripts.=C2=A0 With the possible=C2=A0exception of language s= election when a message is sent with the=C2=A0same basic text in several la= nguages (multipart/alternative was=C2=A0designed with >that case in mind bu= t have been used in other=C2=A0ways), we thought we solved that content pro= blem with MIME in=C2=A01992.=C2=A0 If MIME is inadequate, the authors or ot= hers should=C2=A0produce a document explaining the issues and not confuse >= them=C2=A0with EAI / SMTPUTF8.=C2=A0 If it is adequate, then, like Tony=C2= =A0although perhaps for different reasons, I don't see what Section=C2=A01.= 2 is doing here, what the relevance of Section 3.2 is, and=C2=A0several oth= er statements should be examined >carefully to be sure=C2=A0they are talkin= g about addresses and/or headers and not content. Yes. =C2=A0I see your point. =C2=A0 Let me say first the basic thing that w= e are trying to do is to discuss the holistic user experience of internatio= nalized emails from an operational point of view. =C2=A0 In so doing, the c= o-mingling happened. =C2=A0We could do a second draft for content issues or= change the abstract of this one to better state what our real goal is. Secondly, as you guys know well, there are lots of other issues with IDN, b= rowser support, etc. =C2=A0 What we were actually hoping is that we could h= ave a forum (perhaps like DNSOps or v6Ops) where we could come together to = define and discuss such problems, move towards best practices (or work arou= nds! Not that I like that, but it happens.) =C2=A0 Because we have not even= started on problems that we see such as search algorithm ranking of IDNs a= nd so on. =C2=A0 We were hoping that others would step up to author such ot= her drafts. =C2=A0Thanks, Nalini ElkinsInside Products, Inc.www.insidethestack.com(831) 659-8360 From: John C Klensin To: "HANSEN, TONY L" ; ima@ietf.org=20 Sent: Sunday, October 9, 2016 7:57 PM Subject: Re: [EAI] [IETF] Internationalized Email Internet Draft =20 --On Thursday, October 06, 2016 4:39 PM +0000 "HANSEN, TONY L" wrote: > I think getting deployment feedback from EAI is important, and > this draft is an excellent start. >=20 > I'm not convinced that section 1.2 describes a real problem. > People do this all the time today with various combinations of > languages. Why is the combination of Russian and Chinese any > different? If you think it is, then please expand on the > aspect that does make it more difficult. >=20 > I forwarded a number of nits to the authors. Hi.=C2=A0 I was going to hold off until some later and more mature version of this draft, but since Tony has commented, while I believe the issues with EAI deployment are important, I see several problems with this draft, some of which were actually discussed in the WG but appear to be ignored here.=C2=A0 Perhaps more important, it is seriously incomplete relative to issues that have been discussed at great length in the EAI WG, at the APEC meeting on internationalized email in Beijing in October 2014, the May 2015 workshop in Thailand, and elsewhere.=C2=A0 I strongly suggest that, if there is going to be a discussion in Seoul, this document is in need of a great deal of work first.=C2=A0 Some of those issues are: (1) The so-called EAI standards, as listed in the Introduction, are about email envelope and header information presented directly (e.g., in UTF-8) as non-ASCII characters.=C2=A0 A good deal of the document appears to address mail content information such as textual message bodies, in other scripts.=C2=A0 With the possible exception of language selection when a message is sent with the same basic text in several languages (multipart/alternative was designed with that case in mind but have been used in other ways), we thought we solved that content problem with MIME in 1992.=C2=A0 If MIME is inadequate, the authors or others should produce a document explaining the issues and not confuse them with EAI / SMTPUTF8.=C2=A0 If it is adequate, then, like Tony although perhaps for different reasons, I don't see what Section 1.2 is doing here, what the relevance of Section 3.2 is, and several other statements should be examined carefully to be sure they are talking about addresses and/or headers and not content. (2) Within an address, there is, as the I-D points out and consistent with RFC 5321, a local part and a domain part.=C2=A0 RFCs 6530 and 6531 make it quite clear (at least we thought they did) that they are handled differently.=C2=A0 For the domain part, the rules are laid out in the IDNA2008 specs (RFC 5890ff).=C2=A0 Issues about look-alike characters have been extensively discussed and written about (even though some of us have questioned the quality of some of that work).=C2=A0 It does not seem useful to me to revisit those issues here, especially without reference to the prior work and discussions or if some of the discussion here is wrong or contains obvious omissions.=C2=A0 As an example from the first paragraph of Section 6.1, Latin "c" (U+0063) and Cyrillic "c" (U+0441) are typically written with identical graphemes, but are not on the list.=C2=A0 =C2=A0 More important, while the "paypal" example with U+0430 substituted for "a" (U+0061) has been used repeatedly, including in a careful study in an article that is not cited in this draft, it is possible to write "=D1=80=D0=B0=D1=83=D1=80= =D0=B01" with the first five characters in Cyrillic and the last one a digit (which is script independent) (\u'0440'\u'0430'\u'0443'\u'0440'\u'040'\u'0031' [1]), therefore not even violating conventions prohibiting mixed-script labels. There is, of course, no ambiguity in the A-label form, although the authors quite properly point out that it is not user-friendly. By contrast, Section 1.1 talks about display of email addresses, including the local part ("in Punycode" [2]).=C2=A0 While a mail delivery server is free to create whatever aliases for a mailbox local part it likes, including "xn-t2bmh3a" or "123456", "george" or "example", in general converting a local part using the Punycode algorithm and displaying the result is prohibited by the EAI standards (and, incidentally, RFC5321).=C2=A0 More important, it will often lose information and is potentially very dangerous. (3) Arabic should not be confused with a strictly right-to-left writing system.=C2=A0 I am not aware of any such systems in wide use for contemporary languages today.=C2=A0 The problem is that numerals, whether written in European digits, Arabic or Arabic-Indic digits, Chinese (Han) digits, or many others, have been written left to right since that type of positional notation was invented and became widely used.=C2=A0 As a result, the scripts are referred to (in Unicode-speak) as "bidirectional" or "bidi" [3]. Their implications for domain names and IDNA are the subject of RFC 5893. (4) Multiple addresses for one user (and Section 4).=C2=A0 Keeping in mind that many people maintain a number of identities, and even multiple email addresses, for different purposes, I don't understand what point you are trying to make with this section. Many of us believe that users who have mailboxes whose names involve non-ASCII local parts and who engage in communications outside their primary language group will find it necessary to maintain either separate all-ASCII mailboxes or all-ASCII aliases to their primary mailboxes and to do so for a very long time.=C2=A0 That issue has been extensively analyzed and discussed but this document avoids that work, which is both a problem and an opportunity. (5) Section 2.1 asserts that email servers), implying all of them, store data (messages?) in relational databases.=C2=A0 That is simply false.=C2=A0 Some do; others don't.=C2=A0 Even for those that do, there may be a difference between Unicode-capable data storage and Unicode-capable keys or indexes.=C2=A0 There is also absolutely no requirement that any such system store Unicode strings encoded in UTF-8; many do not.=C2=A0=20 (6) There is a necessary difficulty with SMTPUTF8, which is that one cannot transmit a message with non-ASCII characters in addresses or headers to a system that does not support them. Final delivery systems should probably not accept messages unless they have reason to predict that the mail store will handle them _and_ that the user associated with the target mailbox will be able to retrieve them.=C2=A0 Since a user with an all-ASCII mailbox name might still receive a message with, e.g., a non-ASCII backward-pointing address in the envelope or headers, making that decision is not straightforward.=C2=A0 That leads to a strong case that, if one wants broad deployment of SMTPUTF8, the place to start is with the MUAs (including the Webmail systems) and associated POP and IMAP servers and clients.=C2=A0 The "to various extents" list in the first part of Section 3 is not particularly helpful in that regard. (7) Finally, this is an internationalization (i18n) problem as much as it is an email problem.=C2=A0 Terminology (and, where characters or code points are referred to, their precise identification) is very important because the alternative is typically a good deal of user confusion about what you are talking about and other impediments to making progress.=C2=A0 Saying "English" were you mean "Basic Latin Script" or "ASCII" is not helpful, especially given that 5321 local parts can include any ASCII character and that ASCII is not sufficient to write English.=C2=A0 Conversely, it appears that there are a few places where, correctly or incorrectly, you really do mean "English" when you say that.=C2=A0 Similarly, talking about one particular encoding when you mean "Unicode" is confusing and may be misleading.=C2=A0 RFC 6365 may give you a start on some of the issues. regards, =C2=A0 =C2=A0 john =C2=A0 ------------- [1] I recommend the authors have a look at RFC 5137. [2] Punycode is an encoding method, not a display format.=C2=A0 See RFC 5890, Section=C2=A0 2.3.4.=20 [3] http://unicode.org/reports/tr9/ _______________________________________________ IMA mailing list IMA@ietf.org https://www.ietf.org/mailman/listinfo/ima =20 ------=_Part_216488_699762746.1476451836529 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
John / Tony,
I am going to split your comments into separate threads so = that I can keep track of each.   The first is about co-mingling conten= t vs. headers.

>(1) T= he so-called EAI standards, as listed in the Introduction, are about email envelope and hea= der information presented directly (e.g., in UTF-8) as non-ASCII characters.  A good d= eal of the docum= ent appears to address mail >content information such as textual message bodies, in oth= er scripts.  With the possible exception of language selection when a message is sent = with the same ba= sic text in several languages (multipart/alternative was designed with >that case in mi= nd but have been used in other ways), we thought we solved that content problem with MIME i= n 1992.  If= MIME is inadequate, the authors or others should produce a document explaining the issue= s and not confuse >them with EAI / SMTPUTF8.  If it is adequate, then, like Tony&nb= sp;although perhaps f= or different reasons, I don't see what Section 1.2 is doing here, what the relevance of Sec= tion 3.2 is, and several other statements should be examined >carefully to be sure = they are talking abou= t addresses and/or headers and not content.

Yes.  I see your point.   Let me say first the bas= ic thing that we are trying to do is to discuss the holistic user experience of internati= onalized emails from an operational point of view.   In so doing, the = co-mingling happened.  We could do a second draft for content issues o= r change the abstract of this one to better state what our real goal is.
<= br>
Secondly, as you = guys know well, there are lots of other issues with IDN, browser support, e= tc.   What we were actually hoping is that we could have a forum (perh= aps like DNSOps or v6Ops) where we could come together to define and discus= s such problems, move towards best practices (or work arounds! Not that I l= ike that, but it happens.)   Because we have not even started on probl= ems that we see such as search algorithm ranking of IDNs and so on.   = We were hoping that others would step up to author such other drafts.
=
 
Thanks,

Nalini Elkins
= Inside Products, Inc.
www.insidethestack.com
(831) 659-= 8360


From: John C Klensin &l= t;klensin@jck.com>
To:<= /b> "HANSEN, TONY L" <tony@att.com>; ima@ietf.org
Sent: Sunday, October 9, 2016 7:57 PM Subject: Re: [EAI] [IETF= ] Internationalized Email Internet Draft



--On Thursday, Oc= tober 06, 2016 4:39 PM +0000 "HANSEN, TONY L"
<ton= y@att.com> wrote:

> I think = getting deployment feedback from EAI is important, and
&g= t; this draft is an excellent start.
>
> I'm not convinced that section 1.2 describes a real problem.
> People do this all the time today with various combinatio= ns of
> languages. Why is the combination of Russian a= nd Chinese any
> different? If you think it is, then p= lease expand on the
> aspect that does make it more di= fficult.
>
> I forwarded a numbe= r of nits to the authors.

Hi.  I = was going to hold off until some later and more mature
ve= rsion of this draft, but since Tony has commented, while I
believe the issues with EAI deployment are important, I see
several problems with this draft, some of which were actually
discussed in the WG but appear to be ignored here.  Perhaps = more
important, it is seriously incomplete relative to is= sues that
have been discussed at great length in the EAI = WG, at the APEC
meeting on internationalized email in Bei= jing in October 2014,
the May 2015 workshop in Thailand, = and elsewhere.  I strongly
suggest that, if there is= going to be a discussion in Seoul,
this document is in n= eed of a great deal of work first.  Some of
those is= sues are:

(1) The so-called EAI standa= rds, as listed in the Introduction,
are about email envel= ope and header information presented
directly (e.g., in U= TF-8) as non-ASCII characters.  A good deal
of the d= ocument appears to address mail content information such
= as textual message bodies, in other scripts.  With the possible
exception of language selection when a message is sent with the=
same basic text in several languages (multipart/alternat= ive was
designed with that case in mind but have been use= d in other
ways), we thought we solved that content probl= em with MIME in
1992.  If MIME is inadequate, the au= thors or others should
produce a document explaining the = issues and not confuse them
with EAI / SMTPUTF8.  If= it is adequate, then, like Tony
although perhaps for dif= ferent reasons, I don't see what Section
1.2 is doing her= e, what the relevance of Section 3.2 is, and
several othe= r statements should be examined carefully to be sure
they= are talking about addresses and/or headers and not content.

(2) Within an address, there is, as the I-D points o= ut and
consistent with RFC 5321, a local part and a domai= n part.  RFCs
6530 and 6531 make it quite clear (at = least we thought they did)
that they are handled differen= tly.  For the domain part, the
rules are laid out in= the IDNA2008 specs (RFC 5890ff).  Issues
about look= -alike characters have been extensively discussed and
wri= tten about (even though some of us have questioned the
qu= ality of some of that work).  It does not seem useful to me to
revisit those issues here, especially without reference to theprior work and discussions or if some of the discussion he= re is
wrong or contains obvious omissions.  As an ex= ample from the
first paragraph of Section 6.1, Latin "c" = (U+0063) and Cyrillic
"c" (U+0441) are typically written = with identical graphemes, but
are not on the list.  =   More important, while the "paypal"
example with U+= 0430 substituted for "a" (U+0061) has been used
repeatedl= y, including in a careful study in an article that is
not= cited in this draft, it is possible to write "=D1=80=D0=B0=D1=83=D1=80=D0= =B01"
with the first five characters in Cyrillic and the = last one a
digit (which is script independent)
(\u'0440'\u'0430'\u'0443'\u'0440'\u'040'\u'0031' [1]), therefore<= br clear=3D"none">not even violating conventions prohibiting mixed-script l= abels.
There is, of course, no ambiguity in the A-label f= orm, although
the authors quite properly point out that i= t is not
user-friendly.

By contrast, Section 1.1 talks about display of email addresses,
including the local part ("in Punycode" [2]).  While a mai= l
delivery server is free to create whatever aliases for = a mailbox
local part it likes, including "xn-t2bmh3a" or = "123456",
"george" or "example", in general converting a = local part using
the Punycode algorithm and displaying th= e result is prohibited
by the EAI standards (and, inciden= tally, RFC5321).  More
important, it will often lose= information and is potentially
very dangerous.

(3) Arabic should not be confused with a stric= tly right-to-left
writing system.  I am not aware of= any such systems in wide use
for contemporary languages = today.  The problem is that numerals,
whether writte= n in European digits, Arabic or Arabic-Indic
digits, Chin= ese (Han) digits, or many others, have been written
left = to right since that type of positional notation was
inven= ted and became widely used.  As a result, the scripts are
referred to (in Unicode-speak) as "bidirectional" or "bidi" [3].
Their implications for domain names and IDNA are the subject = of
RFC 5893.

(4) Mul= tiple addresses for one user (and Section 4).  Keeping in
mind that many people maintain a number of identities, and even
multiple email addresses, for different purposes, I don't
understand what point you are trying to make with this sectio= n.
Many of us believe that users who have mailboxes whose= names
involve non-ASCII local parts and who engage in co= mmunications
outside their primary language group will fi= nd it necessary to
maintain either separate all-ASCII mai= lboxes or all-ASCII
aliases to their primary mailboxes an= d to do so for a very long
time.  That issue has bee= n extensively analyzed and discussed
but this document av= oids that work, which is both a problem and
an opportunit= y.

(5) Section 2.1 asserts that email = servers), implying all of
them, store data (messages?) in= relational databases.  That is
simply false.  = Some do; others don't.  Even for those that do,
the= re may be a difference between Unicode-capable data storage
and Unicode-capable keys or indexes.  There is also absolutely
no requirement that any such system store Unicode stringsencoded in UTF-8; many do not. 
(6) There is a necessary difficulty with SMTPUTF8, which is= that
one cannot transmit a message with non-ASCII charac= ters in
addresses or headers to a system that does not su= pport them.
Final delivery systems should probably not ac= cept messages
unless they have reason to predict that the= mail store will
handle them _and_ that the user associat= ed with the target
mailbox will be able to retrieve them.=   Since a user with an
all-ASCII mailbox name might = still receive a message with, e.g.,
a non-ASCII backward-= pointing address in the envelope or
headers, making that = decision is not straightforward.  That
leads to a st= rong case that, if one wants broad deployment of
SMTPUTF8= , the place to start is with the MUAs (including the
Webm= ail systems) and associated POP and IMAP servers and
clie= nts.  The "to various extents" list in the first part of
Section 3 is not particularly helpful in that regard.

(7) Finally, this is an internationalization (i18n) p= roblem as
much as it is an email problem.  Terminolo= gy (and, where
characters or code points are referred to,= their precise
identification) is very important because = the alternative is
typically a good deal of user confusio= n about what you are
talking about and other impediments = to making progress.  Saying
"English" were you mean = "Basic Latin Script" or "ASCII" is not
helpful, especiall= y given that 5321 local parts can include any
ASCII chara= cter and that ASCII is not sufficient to write
English.&n= bsp; Conversely, it appears that there are a few places
w= here, correctly or incorrectly, you really do mean "English"
when you say that.  Similarly, talking about one particular
encoding when you mean "Unicode" is confusing and may be
misleading.  RFC 6365 may give you a start on some of the= issues.

regards,
&n= bsp;   john


&n= bsp; -------------
[1] I recommend the authors have a loo= k at RFC 5137.

[2] Punycode is an enco= ding method, not a display format.  See
RFC 5890, Se= ction  2.3.4.

[3] http://unico= de.org/reports/tr9/


__________________________________________= _____
IMA mailing list
IMA@ietf.org=
https://www.ietf.org/mailman/listinfo/im= a


------=_Part_216488_699762746.1476451836529-- From nobody Fri Oct 14 06:50:50 2016 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98FAC12940E for ; Fri, 14 Oct 2016 06:50:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.42 X-Spam-Level: X-Spam-Status: No, score=-1.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NbD6PBM1iSdL for ; Fri, 14 Oct 2016 06:50:43 -0700 (PDT) Received: from nm27-vm5.bullet.mail.ne1.yahoo.com (nm27-vm5.bullet.mail.ne1.yahoo.com [98.138.91.249]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBE2912977C for ; Fri, 14 Oct 2016 06:50:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1476453031; bh=VXm9ExJmW3HUVqfQj5hnr1pPbgp+7vCPJPEHsftJYVs=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=KZbYr90usBzU+tfVTv5FIfzQsfnh8QWXwQNZwg1NPo/NdVhG26MCtu4gkvSs4WSi313J9Xbdl7rHZF5r7GfgW5iggzlpyBy1zyTFx8LxuCWsNy5wFkSyIxAzKBiDnsm17DXUgGfb/17sEe4R9cFjB5J+oFunpPXfLJulh9nGx07SeL9kZHjwn8mYwrGasu17zR2eWf0TGjqU9tKDinutkQWiM1yJ0WQC/CX16W6ZUyr5ad0zo4C367MpwHcaxVUVq/SjvbaC+1BTXalaNP68wskAFj2LNR1TBYovptRO+cgTjrjzNjkvA2+yBmhDqP8dvFH/JKRXe2bIVfFo7+SXhg== Received: from [98.138.226.176] by nm27.bullet.mail.ne1.yahoo.com with NNFMP; 14 Oct 2016 13:50:31 -0000 Received: from [98.138.89.160] by tm11.bullet.mail.ne1.yahoo.com with NNFMP; 14 Oct 2016 13:50:31 -0000 Received: from [127.0.0.1] by omp1016.mail.ne1.yahoo.com with NNFMP; 14 Oct 2016 13:50:31 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 288319.20617.bm@omp1016.mail.ne1.yahoo.com X-YMail-OSG: bYKieZsVM1mIaDe2uhX2_QbAGYEGlx40l8Atj5Z6JswtmEMYQfed2aR_Uirfj7c V4qwtJ2mgHRYN0p0MOJ4phma4_DSJaX.agl0UB0.pCS9skpzFHznGJvEPqKVs91NR4Z63_xh3Xhs XD7XxzuPqPlRc36ExTeeKpc_JCpdrGyXhNXk4ED3WYYXRVJJcFXWEYGJG.NL7CA8wxlHFWSKEQHW uklRPlU7mH1Zb9yI8RNC1E9v_MLE4_RiDsW6Lb7pEAXKBN1YkYwy6rOw7zTl7s6PZ5tBfSJUlPBB mT9narshQQj0VRMuzA.jy2w59LOfMhF3Yl6L4Ene7n9O5rJmxqH3GwHwQR9rTK2HQxM_sLD2QCoW aPymxioMDQt2jq2_90A82Ocrh86TJYxVrmA3xiotKX5JOnj2UntcnaSPimjpFP4SqZS8tePGU8mf .nqu1uQRYXNzY19UIHHpVqWHo7jSk9GuzmacYmx.nRzeQXwfv6Md3afroeRDZ2vKZg8UfEC9cTY. 76YMNH0geQkF_gcmkXNdySB15Y9WE2nT6zwz0jZ7U66pFE5zLTMw- Received: from jws200148.mail.ne1.yahoo.com by sendmailws141.mail.ne1.yahoo.com; Fri, 14 Oct 2016 13:50:30 +0000; 1476453030.825 Date: Fri, 14 Oct 2016 13:50:30 +0000 (UTC) From: To: John C Klensin , "HANSEN, TONY L" , "ima@ietf.org" Message-ID: <648244759.241596.1476453030456@mail.yahoo.com> In-Reply-To: References: <20161006055447.32573.qmail@pro-236-157.rediffmailpro.com> <9EC0EB65-9C58-43ED-9A80-1DA32C58E3E0@att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [EAI] [IETF] Homographic Attacks [was: Internationalized Email Internet Draft] X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: nalini.elkins@insidethestack.com List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 13:50:48 -0000 John, I am splitting your comment #2 into two parts: Homographic attacks and disp= lay of email addresses. First, homographic attacks: >(2) Within an address, there is, as the I-D points out and consistent with= RFC 5321, a local part and a domain part. RFCs 6530 and 6531 make it quit= e clear (at least we thought they >did) that they are handled differently. = For the domain part, the rules are laid out in the IDNA2008 specs (RFC 589= 0ff). Issues about look-alike characters have been extensively >discussed = and written about (even though some of us have questioned the quality of so= me of that work). It does not seem useful to me to revisit those issues he= re, especially without >reference to the prior work and discussions or if s= ome of the discussion here is wrong or contains obvious omissions.=20 We can certainly refer to the prior work. I will contact you offline for y= our kind assistance. But, I think that the area of homographic attacks is definitely worth talki= ng about. If I might use the example of IPv6, I think at the IETF people t= hink thought that IPv6 was very well defined but operationally, in the "rea= l" world, many people had (and still have!) absolutely no idea how it works= . Many people have NO idea of how homographic attacks work and as we go forth= into a truly internationalized Internet then this is very definitely a top= ic that needs to be discussed - and often! =20 >As an example from the first paragraph of Section 6.1, Latin "c" (U+0063) = and Cyrillic "c" (U+0441) are typically written with identical graphemes, b= utare not on the list. More >important, while the "paypal" example with = U+0430 substituted for "a" (U+0061) has been used repeatedly, including in = a careful study in an article that is not cited in this draft, Will contact you for reference >it is possible to write "=D1=80=D0=B0=D1=83=D1=80=D0=B01" with the first f= ive characters in Cyrillic and the last one a digit (which is script indepe= ndent) (\u'0440'\u'0430'\u'0443'\u'0440'\u'040'\u'0031' [1]), therefore>not= even violating conventions prohibiting mixed-script labels. There is, of c= ourse, no ambiguity in the A-label form, although the authors quite properl= y point out that it is not >user-friendly. Indeed. I think this topic merits much discussion including the area of wh= at the ICANN rules REALLY are in this area and whether registrars are compl= ying. As we get "new blood" into this area, then some of the topics that = are so familiar to you, Tony, and many of the long time members of this WG = will need to be revisited as the rest of us try to catch up to you.=20 But, I hope it will be worth it for the new energy that new people bring. = Not to mention that as concepts proceed into operations, issues that no one= had thought of surface. =20 Thanks, Nalini Elkins Inside Products, Inc. www.insidethestack.com (831) 659-8360 ________________________________ From: John C Klensin To: "HANSEN, TONY L" ; ima@ietf.org=20 Sent: Sunday, October 9, 2016 7:57 PM Subject: Re: [EAI] [IETF] Internationalized Email Internet Draft --On Thursday, October 06, 2016 4:39 PM +0000 "HANSEN, TONY L" wrote: > I think getting deployment feedback from EAI is important, and > this draft is an excellent start. >=20 > I'm not convinced that section 1.2 describes a real problem. > People do this all the time today with various combinations of > languages. Why is the combination of Russian and Chinese any > different? If you think it is, then please expand on the > aspect that does make it more difficult. >=20 > I forwarded a number of nits to the authors. Hi. I was going to hold off until some later and more mature version of this draft, but since Tony has commented, while I believe the issues with EAI deployment are important, I see several problems with this draft, some of which were actually discussed in the WG but appear to be ignored here. Perhaps more important, it is seriously incomplete relative to issues that have been discussed at great length in the EAI WG, at the APEC meeting on internationalized email in Beijing in October 2014, the May 2015 workshop in Thailand, and elsewhere. I strongly suggest that, if there is going to be a discussion in Seoul, this document is in need of a great deal of work first. Some of those issues are: (1) The so-called EAI standards, as listed in the Introduction, are about email envelope and header information presented directly (e.g., in UTF-8) as non-ASCII characters. A good deal of the document appears to address mail content information such as textual message bodies, in other scripts. With the possible exception of language selection when a message is sent with the same basic text in several languages (multipart/alternative was designed with that case in mind but have been used in other ways), we thought we solved that content problem with MIME in 1992. If MIME is inadequate, the authors or others should produce a document explaining the issues and not confuse them with EAI / SMTPUTF8. If it is adequate, then, like Tony although perhaps for different reasons, I don't see what Section 1.2 is doing here, what the relevance of Section 3.2 is, and several other statements should be examined carefully to be sure they are talking about addresses and/or headers and not content. (2) Within an address, there is, as the I-D points out and consistent with RFC 5321, a local part and a domain part. RFCs 6530 and 6531 make it quite clear (at least we thought they did) that they are handled differently. For the domain part, the rules are laid out in the IDNA2008 specs (RFC 5890ff). Issues about look-alike characters have been extensively discussed and written about (even though some of us have questioned the quality of some of that work). It does not seem useful to me to revisit those issues here, especially without reference to the prior work and discussions or if some of the discussion here is wrong or contains obvious omissions. As an example from the first paragraph of Section 6.1, Latin "c" (U+0063) and Cyrillic "c" (U+0441) are typically written with identical graphemes, but are not on the list. More important, while the "paypal" example with U+0430 substituted for "a" (U+0061) has been used repeatedly, including in a careful study in an article that is not cited in this draft, it is possible to write "=D1=80=D0=B0=D1=83=D1=80= =D0=B01" with the first five characters in Cyrillic and the last one a digit (which is script independent) (\u'0440'\u'0430'\u'0443'\u'0440'\u'040'\u'0031' [1]), therefore not even violating conventions prohibiting mixed-script labels. There is, of course, no ambiguity in the A-label form, although the authors quite properly point out that it is not user-friendly. By contrast, Section 1.1 talks about display of email addresses, including the local part ("in Punycode" [2]). While a mail delivery server is free to create whatever aliases for a mailbox local part it likes, including "xn-t2bmh3a" or "123456", "george" or "example", in general converting a local part using the Punycode algorithm and displaying the result is prohibited by the EAI standards (and, incidentally, RFC5321). More important, it will often lose information and is potentially very dangerous. (3) Arabic should not be confused with a strictly right-to-left writing system. I am not aware of any such systems in wide use for contemporary languages today. The problem is that numerals, whether written in European digits, Arabic or Arabic-Indic digits, Chinese (Han) digits, or many others, have been written left to right since that type of positional notation was invented and became widely used. As a result, the scripts are referred to (in Unicode-speak) as "bidirectional" or "bidi" [3]. Their implications for domain names and IDNA are the subject of RFC 5893. (4) Multiple addresses for one user (and Section 4). Keeping in mind that many people maintain a number of identities, and even multiple email addresses, for different purposes, I don't understand what point you are trying to make with this section. Many of us believe that users who have mailboxes whose names involve non-ASCII local parts and who engage in communications outside their primary language group will find it necessary to maintain either separate all-ASCII mailboxes or all-ASCII aliases to their primary mailboxes and to do so for a very long time. That issue has been extensively analyzed and discussed but this document avoids that work, which is both a problem and an opportunity. (5) Section 2.1 asserts that email servers), implying all of them, store data (messages?) in relational databases. That is simply false. Some do; others don't. Even for those that do, there may be a difference between Unicode-capable data storage and Unicode-capable keys or indexes. There is also absolutely no requirement that any such system store Unicode strings encoded in UTF-8; many do not. =20 (6) There is a necessary difficulty with SMTPUTF8, which is that one cannot transmit a message with non-ASCII characters in addresses or headers to a system that does not support them. Final delivery systems should probably not accept messages unless they have reason to predict that the mail store will handle them _and_ that the user associated with the target mailbox will be able to retrieve them. Since a user with an all-ASCII mailbox name might still receive a message with, e.g., a non-ASCII backward-pointing address in the envelope or headers, making that decision is not straightforward. That leads to a strong case that, if one wants broad deployment of SMTPUTF8, the place to start is with the MUAs (including the Webmail systems) and associated POP and IMAP servers and clients. The "to various extents" list in the first part of Section 3 is not particularly helpful in that regard. (7) Finally, this is an internationalization (i18n) problem as much as it is an email problem. Terminology (and, where characters or code points are referred to, their precise identification) is very important because the alternative is typically a good deal of user confusion about what you are talking about and other impediments to making progress. Saying "English" were you mean "Basic Latin Script" or "ASCII" is not helpful, especially given that 5321 local parts can include any ASCII character and that ASCII is not sufficient to write English. Conversely, it appears that there are a few places where, correctly or incorrectly, you really do mean "English" when you say that. Similarly, talking about one particular encoding when you mean "Unicode" is confusing and may be misleading. RFC 6365 may give you a start on some of the issues. regards, john ------------- [1] I recommend the authors have a look at RFC 5137. [2] Punycode is an encoding method, not a display format. See RFC 5890, Section 2.3.4.=20 [3] http://unicode.org/reports/tr9/ _______________________________________________ IMA mailing list IMA@ietf.org https://www.ietf.org/mailman/listinfo/ima From nobody Fri Oct 14 07:49:20 2016 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B7A21297DA for ; Fri, 14 Oct 2016 07:49:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s_JiyUpKRzyD for ; Fri, 14 Oct 2016 07:49:14 -0700 (PDT) Received: from nm21-vm4.bullet.mail.ne1.yahoo.com (nm21-vm4.bullet.mail.ne1.yahoo.com [98.138.91.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD8581297F6 for ; Fri, 14 Oct 2016 07:49:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1476456553; bh=HxlX3pvM7cF4c8bxDEet+uUmV4j1AqUTpibQDOwtowI=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=qbdQzNPzU6FjfNxz6HecD/zqc+Bqp0BdTECfYUe+IQyyCIraU1kTRSrpVD7xbDX6mh9m0CLCWS22pL1wl1VAOen0QoDDWYumT44lWktBMrhgFI/9xZ0RHOi0WcHTfd2l17/oOY3lTTvPOXXQM6qb4G6vtPOQIUmp6OrSot/JnCyy5++iXPKLTsg/obQnufhOmWavFrHZMLo5v6+q9nKPKwg7Q+J/XRFhIlIwJSlJzrdZm6noSRRMbIM+IcvtyhezmSTMDp3Ma4RvD7mLqOpzjYg7Teg89KjYl1tPevqoRFT3vzQsa+Ffmgob7OHFSUm4MdcmSrNFviTE1UjFYAmYzA== Received: from [98.138.100.118] by nm21.bullet.mail.ne1.yahoo.com with NNFMP; 14 Oct 2016 14:49:13 -0000 Received: from [98.138.87.2] by tm109.bullet.mail.ne1.yahoo.com with NNFMP; 14 Oct 2016 14:49:13 -0000 Received: from [127.0.0.1] by omp1002.mail.ne1.yahoo.com with NNFMP; 14 Oct 2016 14:49:13 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 140237.59364.bm@omp1002.mail.ne1.yahoo.com X-YMail-OSG: 4HWuIhEVM1nItSNEuVs3HLcJRu4abOYD0UNd2dHz8AddLkwkvZTaFXJCAH8vVNv 63lQVtQ0GMoNiAIhbw_0O4sXWV8jSMaVVgBSbqqytlGzNBjTPl3JncvD1uUyHt0tadikNuujP.YC u0sIK2taebtWZZDwCZDzQKIX9.joGnmZUH0Zm7wFePn1OndcDU6vRLv6Y_sksQSwFQg8TtpnR0dY 3QiqwRDi4rVjdvmuLpopjwQ.zxHve021VSMIPJctcUQRNF8WBik2pc0NRmiVTrFRAOGNeh46XnkO uvFhCweD8vfa9sn4IEVgwmTOsjTdg9otm7131tJNTaqvngTrG73YH2m2CX3TnTEwuvqEedw1yoMn gA2cTce0LqZAe4BLg44AB6abohdXfMJb6sm_wALjTmAz0.Ztvssx7fwT.z8a2R7u_zp.ldYjXUsw QXIeAzjlYFJR9Wem68EUhOLoApNBmigZfSYvL06DReVNu4kCdeh6T2Q.5MkNuNvq5rDDM8hsIHNB _azEaMG5hQNABcb7vAVJAo1x4PfiF9W6pzl5ccnjKmdFKGXYPfoE- Received: from jws200056.mail.ne1.yahoo.com by sendmailws130.mail.ne1.yahoo.com; Fri, 14 Oct 2016 14:49:12 +0000; 1476456552.741 Date: Fri, 14 Oct 2016 14:49:12 +0000 (UTC) From: To: John C Klensin , "HANSEN, TONY L" , "ima@ietf.org" Message-ID: <1600128477.303347.1476456552432@mail.yahoo.com> In-Reply-To: References: <20161006055447.32573.qmail@pro-236-157.rediffmailpro.com> <9EC0EB65-9C58-43ED-9A80-1DA32C58E3E0@att.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_303346_1587276494.1476456552427" Archived-At: Cc: Harish Chowdhary Subject: [EAI] [IETF] Display of Email Addresses [was: Internationalized Email Internet Draft] X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: nalini.elkins@insidethestack.com List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 14:49:19 -0000 ------=_Part_303346_1587276494.1476456552427 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable John / Tony, Continuing my splitting of topics! =C2=A0 Hope this makes some kind of sens= e to others. >By contrast, Section 1.1 talks about display of email addresses,=C2=A0incl= uding the local part ("in Punycode" [2]).=C2=A0 While a mail=C2=A0delivery = server is free to create whatever aliases for a ?>mailbox=C2=A0local part i= t likes, including "xn-t2bmh3a" or "123456",=C2=A0"george" or "example", in= general converting a local part using=C2=A0the Punycode algorithm and disp= laying the result is >prohibited=C2=A0by the EAI standards (and, incidental= ly, RFC5321).=C2=A0 More=C2=A0important, it will often lose information and= is potentially=C2=A0very dangerous. This is a very interesting problem. =C2=A0 We are hoping to do some kind of= spreadsheet or other visual where we can show what happens with a number o= f mail servers. =C2=A0For example, what does Yahoo mail do, what does gmail= do,=C2=A0why some clients fail,=C2=A0etc. =C2=A0 I am in the process of setting up a demo system for all this. =C2=A0Let me = tell you, I have learned quite a bit. =C2=A0 Including about DNS queries wh= ich don't resolve properly. =C2=A0Sigh. =C2=A0That is still ANOTHER topic. = =C2=A0 As I say, I want to get organized and have a good way to show this. = =C2=A0 Not quite there yet! =C2=A0 Thanks, Nalini Elkins Inside Products, Inc. www.insidethestack.com (831) 659-8360 ________________________________ From: John C Klensin To: "HANSEN, TONY L" ; ima@ietf.org=20 Sent: Sunday, October 9, 2016 7:57 PM Subject: Re: [EAI] [IETF] Internationalized Email Internet Draft =20 --On Thursday, October 06, 2016 4:39 PM +0000 "HANSEN, TONY L" wrote: > I think getting deployment feedback from EAI is important, and > this draft is an excellent start. >=20 > I'm not convinced that section 1.2 describes a real problem. > People do this all the time today with various combinations of > languages. Why is the combination of Russian and Chinese any > different? If you think it is, then please expand on the > aspect that does make it more difficult. >=20 > I forwarded a number of nits to the authors. Hi.=C2=A0 I was going to hold off until some later and more mature version of this draft, but since Tony has commented, while I believe the issues with EAI deployment are important, I see several problems with this draft, some of which were actually discussed in the WG but appear to be ignored here.=C2=A0 Perhaps more important, it is seriously incomplete relative to issues that have been discussed at great length in the EAI WG, at the APEC meeting on internationalized email in Beijing in October 2014, the May 2015 workshop in Thailand, and elsewhere.=C2=A0 I strongly suggest that, if there is going to be a discussion in Seoul, this document is in need of a great deal of work first.=C2=A0 Some of those issues are: (1) The so-called EAI standards, as listed in the Introduction, are about email envelope and header information presented directly (e.g., in UTF-8) as non-ASCII characters.=C2=A0 A good deal of the document appears to address mail content information such as textual message bodies, in other scripts.=C2=A0 With the possible exception of language selection when a message is sent with the same basic text in several languages (multipart/alternative was designed with that case in mind but have been used in other ways), we thought we solved that content problem with MIME in 1992.=C2=A0 If MIME is inadequate, the authors or others should produce a document explaining the issues and not confuse them with EAI / SMTPUTF8.=C2=A0 If it is adequate, then, like Tony although perhaps for different reasons, I don't see what Section 1.2 is doing here, what the relevance of Section 3.2 is, and several other statements should be examined carefully to be sure they are talking about addresses and/or headers and not content. (2) Within an address, there is, as the I-D points out and consistent with RFC 5321, a local part and a domain part.=C2=A0 RFCs 6530 and 6531 make it quite clear (at least we thought they did) that they are handled differently.=C2=A0 For the domain part, the rules are laid out in the IDNA2008 specs (RFC 5890ff).=C2=A0 Issues about look-alike characters have been extensively discussed and written about (even though some of us have questioned the quality of some of that work).=C2=A0 It does not seem useful to me to revisit those issues here, especially without reference to the prior work and discussions or if some of the discussion here is wrong or contains obvious omissions.=C2=A0 As an example from the first paragraph of Section 6.1, Latin "c" (U+0063) and Cyrillic "c" (U+0441) are typically written with identical graphemes, but are not on the list.=C2=A0 =C2=A0 More important, while the "paypal" example with U+0430 substituted for "a" (U+0061) has been used repeatedly, including in a careful study in an article that is not cited in this draft, it is possible to write "=D1=80=D0=B0=D1=83=D1=80= =D0=B01" with the first five characters in Cyrillic and the last one a digit (which is script independent) (\u'0440'\u'0430'\u'0443'\u'0440'\u'040'\u'0031' [1]), therefore not even violating conventions prohibiting mixed-script labels. There is, of course, no ambiguity in the A-label form, although the authors quite properly point out that it is not user-friendly. By contrast, Section 1.1 talks about display of email addresses, including the local part ("in Punycode" [2]).=C2=A0 While a mail delivery server is free to create whatever aliases for a mailbox local part it likes, including "xn-t2bmh3a" or "123456", "george" or "example", in general converting a local part using the Punycode algorithm and displaying the result is prohibited by the EAI standards (and, incidentally, RFC5321).=C2=A0 More important, it will often lose information and is potentially very dangerous. (3) Arabic should not be confused with a strictly right-to-left writing system.=C2=A0 I am not aware of any such systems in wide use for contemporary languages today.=C2=A0 The problem is that numerals, whether written in European digits, Arabic or Arabic-Indic digits, Chinese (Han) digits, or many others, have been written left to right since that type of positional notation was invented and became widely used.=C2=A0 As a result, the scripts are referred to (in Unicode-speak) as "bidirectional" or "bidi" [3]. Their implications for domain names and IDNA are the subject of RFC 5893. (4) Multiple addresses for one user (and Section 4).=C2=A0 Keeping in mind that many people maintain a number of identities, and even multiple email addresses, for different purposes, I don't understand what point you are trying to make with this section. Many of us believe that users who have mailboxes whose names involve non-ASCII local parts and who engage in communications outside their primary language group will find it necessary to maintain either separate all-ASCII mailboxes or all-ASCII aliases to their primary mailboxes and to do so for a very long time.=C2=A0 That issue has been extensively analyzed and discussed but this document avoids that work, which is both a problem and an opportunity. (5) Section 2.1 asserts that email servers), implying all of them, store data (messages?) in relational databases.=C2=A0 That is simply false.=C2=A0 Some do; others don't.=C2=A0 Even for those that do, there may be a difference between Unicode-capable data storage and Unicode-capable keys or indexes.=C2=A0 There is also absolutely no requirement that any such system store Unicode strings encoded in UTF-8; many do not.=C2=A0=20 (6) There is a necessary difficulty with SMTPUTF8, which is that one cannot transmit a message with non-ASCII characters in addresses or headers to a system that does not support them. Final delivery systems should probably not accept messages unless they have reason to predict that the mail store will handle them _and_ that the user associated with the target mailbox will be able to retrieve them.=C2=A0 Since a user with an all-ASCII mailbox name might still receive a message with, e.g., a non-ASCII backward-pointing address in the envelope or headers, making that decision is not straightforward.=C2=A0 That leads to a strong case that, if one wants broad deployment of SMTPUTF8, the place to start is with the MUAs (including the Webmail systems) and associated POP and IMAP servers and clients.=C2=A0 The "to various extents" list in the first part of Section 3 is not particularly helpful in that regard. (7) Finally, this is an internationalization (i18n) problem as much as it is an email problem.=C2=A0 Terminology (and, where characters or code points are referred to, their precise identification) is very important because the alternative is typically a good deal of user confusion about what you are talking about and other impediments to making progress.=C2=A0 Saying "English" were you mean "Basic Latin Script" or "ASCII" is not helpful, especially given that 5321 local parts can include any ASCII character and that ASCII is not sufficient to write English.=C2=A0 Conversely, it appears that there are a few places where, correctly or incorrectly, you really do mean "English" when you say that.=C2=A0 Similarly, talking about one particular encoding when you mean "Unicode" is confusing and may be misleading.=C2=A0 RFC 6365 may give you a start on some of the issues. regards, =C2=A0 =C2=A0 john =C2=A0 ------------- [1] I recommend the authors have a look at RFC 5137. [2] Punycode is an encoding method, not a display format.=C2=A0 See RFC 5890, Section=C2=A0 2.3.4.=20 [3] http://unicode.org/reports/tr9/ _______________________________________________ IMA mailing list IMA@ietf.org https://www.ietf.org/mailman/listinfo/ima ------=_Part_303346_1587276494.1476456552427 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
John / Tony,

=
Continuing my splitting o= f topics!   Hope this makes some kind of sense to others.

>By contrast, Secti= on 1.1 talks about display of email addresses, including the local par= t ("in Punycode" [2]).  While a mail delivery server is free to c= reate whatever aliases for a ?>mailbox local part it likes, includi= ng "xn-t2bmh3a" or "123456", "george" or "example", in general convert= ing a local part using the Punycode algorithm and displaying the resul= t is >prohibited by the EAI standards (and, incidentally, RFC5321).=   More important, it will often lose information and is potential= ly very dangerous.


This is a very interesting p= roblem.   We are hoping to do some kind of spreadsheet or other visual= where we can show what happens with a number of mail servers.  For ex= ample, what does Yahoo mail do, what does gmail do, why some cli= ents fail, etc.  

I am in the process of setting up a demo system fo= r all this.  Let me tell you, I have learned quite a bit.   Inclu= ding about DNS queries which don't resolve properly.  Sigh.  That= is still ANOTHER topic.   As I say, I want to get organized and have = a good way to show this.   Not quite there yet!

 
Tha= nks,

Nalini Elkins
Inside Products, Inc.
www.insidethestack.co= m
(831) 659-8360



________________________________
Fro= m: John C Klensin <klensin@jck.com>
To: "HANSEN, TONY L" <tony@= att.com>; ima@ietf.org
Sent: Sunday, October 9, 2016 7:57 PM
Subj= ect: Re: [EAI] [IETF] Internationalized Email Internet Draft



--On Thursday, October 06, 2016 4:39 PM +0000 "HANSEN, TONY L"
<= ;tony@att.com> wrote:

> I think getting deployment feedback fr= om EAI is important, and
> this draft is an excellent start.
> =
> I'm not convinced that section 1.2 describes a real problem.
&g= t; People do this all the time today with various combinations of
> l= anguages. Why is the combination of Russian and Chinese any
> differe= nt? If you think it is, then please expand on the
> aspect that does = make it more difficult.
>
> I forwarded a number of nits to th= e authors.

Hi.  I was going to hold off until some later and mo= re mature
version of this draft, but since Tony has commented, while Ibelieve the issues with EAI deployment are important, I see
several pr= oblems with this draft, some of which were actually
discussed in the WG = but appear to be ignored here.  Perhaps more
important, it is serio= usly incomplete relative to issues that
have been discussed at great len= gth in the EAI WG, at the APEC
meeting on internationalized email in Bei= jing in October 2014,
the May 2015 workshop in Thailand, and elsewhere.&= nbsp; I strongly
suggest that, if there is going to be a discussion in S= eoul,
this document is in need of a great deal of work first.  Some= of
those issues are:

(1) The so-called EAI standards, as listed = in the Introduction,
are about email envelope and header information pre= sented
directly (e.g., in UTF-8) as non-ASCII characters.  A good d= eal
of the document appears to address mail content information such
= as textual message bodies, in other scripts.  With the possible
exc= eption of language selection when a message is sent with the
same basic = text in several languages (multipart/alternative was
designed with that = case in mind but have been used in other
ways), we thought we solved tha= t content problem with MIME in
1992.  If MIME is inadequate, the au= thors or others should
produce a document explaining the issues and not = confuse them
with EAI / SMTPUTF8.  If it is adequate, then, like To= ny
although perhaps for different reasons, I don't see what Section
1= .2 is doing here, what the relevance of Section 3.2 is, and
several othe= r statements should be examined carefully to be sure
they are talking ab= out addresses and/or headers and not content.

(2) Within an address,= there is, as the I-D points out and
consistent with RFC 5321, a local p= art and a domain part.  RFCs
6530 and 6531 make it quite clear (at = least we thought they did)
that they are handled differently.  For = the domain part, the
rules are laid out in the IDNA2008 specs (RFC 5890f= f).  Issues
about look-alike characters have been extensively discu= ssed and
written about (even though some of us have questioned the
qu= ality of some of that work).  It does not seem useful to me to
revi= sit those issues here, especially without reference to the
prior work an= d discussions or if some of the discussion here is
wrong or contains obv= ious omissions.  As an example from the
first paragraph of Section = 6.1, Latin "c" (U+0063) and Cyrillic
"c" (U+0441) are typically written = with identical graphemes, but
are not on the list.    More imp= ortant, while the "paypal"
example with U+0430 substituted for "a" (U+00= 61) has been used
repeatedly, including in a careful study in an article= that is
not cited in this draft, it is possible to write "=D1=80=D0=B0= =D1=83=D1=80=D0=B01"
with the first five characters in Cyrillic and the = last one a
digit (which is script independent)
(\u'0440'\u'0430'\u'04= 43'\u'0440'\u'040'\u'0031' [1]), therefore
not even violating convention= s prohibiting mixed-script labels.
There is, of course, no ambiguity in = the A-label form, although
the authors quite properly point out that it = is not
user-friendly.

By contrast, Section 1.1 talks about displa= y of email addresses,
including the local part ("in Punycode" [2]). = ; While a mail
delivery server is free to create whatever aliases for a = mailbox
local part it likes, including "xn-t2bmh3a" or "123456",
"geo= rge" or "example", in general converting a local part using
the Punycode= algorithm and displaying the result is prohibited
by the EAI standards = (and, incidentally, RFC5321).  More
important, it will often lose i= nformation and is potentially
very dangerous.

(3) Arabic should n= ot be confused with a strictly right-to-left
writing system.  I am = not aware of any such systems in wide use
for contemporary languages tod= ay.  The problem is that numerals,
whether written in European digi= ts, Arabic or Arabic-Indic
digits, Chinese (Han) digits, or many others,= have been written
left to right since that type of positional notation = was
invented and became widely used.  As a result, the scripts are<= br>referred to (in Unicode-speak) as "bidirectional" or "bidi" [3].
Thei= r implications for domain names and IDNA are the subject of
RFC 5893.
(4) Multiple addresses for one user (and Section 4).  Keeping in<= br>mind that many people maintain a number of identities, and even
multi= ple email addresses, for different purposes, I don't
understand what poi= nt you are trying to make with this section.
Many of us believe that use= rs who have mailboxes whose names
involve non-ASCII local parts and who = engage in communications
outside their primary language group will find = it necessary to
maintain either separate all-ASCII mailboxes or all-ASCI= I
aliases to their primary mailboxes and to do so for a very long
tim= e.  That issue has been extensively analyzed and discussed
but this= document avoids that work, which is both a problem and
an opportunity.<= br>
(5) Section 2.1 asserts that email servers), implying all of
them= , store data (messages?) in relational databases.  That is
simply f= alse.  Some do; others don't.  Even for those that do,
there = may be a difference between Unicode-capable data storage
and Unicode-cap= able keys or indexes.  There is also absolutely
no requirement tha= t any such system store Unicode strings
encoded in UTF-8; many do not.&n= bsp;

(6) There is a necessary difficulty with SMTPUTF8, which is th= at
one cannot transmit a message with non-ASCII characters in
address= es or headers to a system that does not support them.
Final delivery sys= tems should probably not accept messages
unless they have reason to pred= ict that the mail store will
handle them _and_ that the user associated = with the target
mailbox will be able to retrieve them.  Since a use= r with an
all-ASCII mailbox name might still receive a message with, e.g= .,
a non-ASCII backward-pointing address in the envelope or
headers, = making that decision is not straightforward.  That
leads to a stron= g case that, if one wants broad deployment of
SMTPUTF8, the place to sta= rt is with the MUAs (including the
Webmail systems) and associated POP a= nd IMAP servers and
clients.  The "to various extents" list in the= first part of
Section 3 is not particularly helpful in that regard.
=
(7) Finally, this is an internationalization (i18n) problem as
much = as it is an email problem.  Terminology (and, where
characters or c= ode points are referred to, their precise
identification) is very import= ant because the alternative is
typically a good deal of user confusion a= bout what you are
talking about and other impediments to making progress= .  Saying
"English" were you mean "Basic Latin Script" or "ASCII" i= s not
helpful, especially given that 5321 local parts can include anyASCII character and that ASCII is not sufficient to write
English. = ; Conversely, it appears that there are a few places
where, correctly or= incorrectly, you really do mean "English"
when you say that.  Sim= ilarly, talking about one particular
encoding when you mean "Unicode" is= confusing and may be
misleading.  RFC 6365 may give you a start on= some of the issues.

regards,
    john


 = ; -------------
[1] I recommend the authors have a look at RFC 5137.
=
[2] Punycode is an encoding method, not a display format.  See
= RFC 5890, Section  2.3.4.

[3] http://unicode.org/reports/tr9/<= br>

_______________________________________________
IMA mailing l= ist
IMA@ietf.org
https://www.ietf.org/mailman/listinfo/ima
------=_Part_303346_1587276494.1476456552427-- From nobody Fri Oct 14 07:54:50 2016 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCA3C129825 for ; Fri, 14 Oct 2016 07:54:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.419 X-Spam-Level: X-Spam-Status: No, score=-1.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JhlYZzC1Limr for ; Fri, 14 Oct 2016 07:54:44 -0700 (PDT) Received: from nm20-vm4.bullet.mail.ne1.yahoo.com (nm20-vm4.bullet.mail.ne1.yahoo.com [98.138.91.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C5CA129830 for ; Fri, 14 Oct 2016 07:54:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1476456867; bh=mQcBjA2lMZcqORE2xkBaOI1VU+S8vi3EgBeKAo7RBZg=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=RM78/gNxBd84PehdyIUWOCVr/eD5aV+b/WDqMTZz+0DZm/5ZXFoN3cKIN1XtwL6fhXauOQsY4VTjh9qr5EV3GZqih7vD3v6zT8VrKGGfOMCAIvw81yWxQF4n5CBQr4v9ytuSxOl+sTN332Ss1uP6+iAIJbG3DSwJ6G0ElyguPrTDaXYuEvNM+ugBeHHvBpdB6WQgSWQCkaFrRplOdJYUZmlsBu+mU1/num4+MDGbwlIuvaQRs8i/oUocofoHyt3u/mXuek3Zi38fzfgqjzPNojyEqr8UPopofxFDYuY0rPb1/vPUgtBnsYaliEk5GZV8kuRKumimbAOdz0rPrZqrqA== Received: from [98.138.100.102] by nm20.bullet.mail.ne1.yahoo.com with NNFMP; 14 Oct 2016 14:54:27 -0000 Received: from [98.138.89.172] by tm101.bullet.mail.ne1.yahoo.com with NNFMP; 14 Oct 2016 14:54:27 -0000 Received: from [127.0.0.1] by omp1028.mail.ne1.yahoo.com with NNFMP; 14 Oct 2016 14:54:27 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 872179.14617.bm@omp1028.mail.ne1.yahoo.com X-YMail-OSG: lm5idPAVM1kwpyAvEZbT9yUVHjIeSqOr0FKrORimoZX8vF36EDHjKlmwyWfspYK qzyUzbGEelH0Ljde_uPqOkdGDlsjbZsO6T0m6r2fqIDn3kgGI19o48YBXFwSS2_NfbYiOvpV3dwc d4bPML5wsiXIc.SOVXq4iDEuzL3CENGWr0PKI8f5ddLJeUfIWpKR.SVHgxq.sQjNGffFdInNqE1X rRpkeDk99ikJ4QTXjYSImD6DIwSWBpslzbI8D1FxZdkXVtAERoSwjM6X5DXRN7cEfwX_hwGkIjZ_ HoE0I67ZCdiFhyjads4iyB1mgFyDVBr3xb6hpq0U7Fo9MfLJ2Gxh_W5OikEWvXA1gJ54vlDJqkal IBFDgLPeuavrKV1I1JkkNZYeC3hHpIIq9jeItdRJW1RTTSygbOKOuoPKubSN0fzhE9mAyq7JllAl 0w2NwkFWu4vbx.4s97Rm3IhLlNnMUr8PvBBzAb5Vpexe9kmzgaOC6wKUijV2.IIgPYQodERROLmX W8MwLVwFUsUcssLh6pllBRrwevHscAtLR03VuP17tSAmrDriBufQ- Received: from jws200145.mail.ne1.yahoo.com by sendmailws101.mail.ne1.yahoo.com; Fri, 14 Oct 2016 14:54:27 +0000; 1476456867.459 Date: Fri, 14 Oct 2016 14:54:26 +0000 (UTC) From: To: John C Klensin , "HANSEN, TONY L" , "ima@ietf.org" Message-ID: <821779948.287120.1476456866330@mail.yahoo.com> In-Reply-To: References: <20161006055447.32573.qmail@pro-236-157.rediffmailpro.com> <9EC0EB65-9C58-43ED-9A80-1DA32C58E3E0@att.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_287119_486004661.1476456866325" Archived-At: Cc: Harish Chowdhary Subject: [EAI] [IETF] Arabic / Bidirectional Writing Systems [was: Internationalized Email Internet Draft] X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: nalini.elkins@insidethestack.com List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 14:54:49 -0000 ------=_Part_287119_486004661.1476456866325 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable John / Tony, >(3) Arabic should not be confused with a strictly right-to-left=C2=A0writi= ng system.=C2=A0 I am not aware of any such systems in wide use=C2=A0for co= ntemporary languages today.=C2=A0 The problem is that> numerals,=C2=A0wheth= er written in European digits, Arabic or Arabic-Indic=C2=A0digits, Chinese = (Han) digits, or many others, have been written=C2=A0left to right since th= at type of positional notation was> invented and became widely used.=C2=A0 = As a result, the scripts are=C2=A0referred to (in Unicode-speak) as "bidire= ctional" or "bidi" [3]. Will change to say "bidi". =C2=A0 I am very curious as to the "on the ground" implications of this. =C2=A0 I = have heard that there is some activity in setting up a test bed for EAI for= Arabic languages. =C2=A0 Is there anyone who can comment on real life prob= lems and issues? >Their implications for domain names and IDNA are the subject of RFC 5893. Will cite. =C2=A0 Thanks, Nalini Elkins Inside Products, Inc. www.insidethestack.com (831) 659-8360 ________________________________ From: John C Klensin To: "HANSEN, TONY L" ; ima@ietf.org=20 Sent: Sunday, October 9, 2016 7:57 PM Subject: Re: [EAI] [IETF] Internationalized Email Internet Draft =20 --On Thursday, October 06, 2016 4:39 PM +0000 "HANSEN, TONY L" wrote: > I think getting deployment feedback from EAI is important, and > this draft is an excellent start. >=20 > I'm not convinced that section 1.2 describes a real problem. > People do this all the time today with various combinations of > languages. Why is the combination of Russian and Chinese any > different? If you think it is, then please expand on the > aspect that does make it more difficult. >=20 > I forwarded a number of nits to the authors. Hi.=C2=A0 I was going to hold off until some later and more mature version of this draft, but since Tony has commented, while I believe the issues with EAI deployment are important, I see several problems with this draft, some of which were actually discussed in the WG but appear to be ignored here.=C2=A0 Perhaps more important, it is seriously incomplete relative to issues that have been discussed at great length in the EAI WG, at the APEC meeting on internationalized email in Beijing in October 2014, the May 2015 workshop in Thailand, and elsewhere.=C2=A0 I strongly suggest that, if there is going to be a discussion in Seoul, this document is in need of a great deal of work first.=C2=A0 Some of those issues are: (1) The so-called EAI standards, as listed in the Introduction, are about email envelope and header information presented directly (e.g., in UTF-8) as non-ASCII characters.=C2=A0 A good deal of the document appears to address mail content information such as textual message bodies, in other scripts.=C2=A0 With the possible exception of language selection when a message is sent with the same basic text in several languages (multipart/alternative was designed with that case in mind but have been used in other ways), we thought we solved that content problem with MIME in 1992.=C2=A0 If MIME is inadequate, the authors or others should produce a document explaining the issues and not confuse them with EAI / SMTPUTF8.=C2=A0 If it is adequate, then, like Tony although perhaps for different reasons, I don't see what Section 1.2 is doing here, what the relevance of Section 3.2 is, and several other statements should be examined carefully to be sure they are talking about addresses and/or headers and not content. (2) Within an address, there is, as the I-D points out and consistent with RFC 5321, a local part and a domain part.=C2=A0 RFCs 6530 and 6531 make it quite clear (at least we thought they did) that they are handled differently.=C2=A0 For the domain part, the rules are laid out in the IDNA2008 specs (RFC 5890ff).=C2=A0 Issues about look-alike characters have been extensively discussed and written about (even though some of us have questioned the quality of some of that work).=C2=A0 It does not seem useful to me to revisit those issues here, especially without reference to the prior work and discussions or if some of the discussion here is wrong or contains obvious omissions.=C2=A0 As an example from the first paragraph of Section 6.1, Latin "c" (U+0063) and Cyrillic "c" (U+0441) are typically written with identical graphemes, but are not on the list.=C2=A0 =C2=A0 More important, while the "paypal" example with U+0430 substituted for "a" (U+0061) has been used repeatedly, including in a careful study in an article that is not cited in this draft, it is possible to write "=D1=80=D0=B0=D1=83=D1=80= =D0=B01" with the first five characters in Cyrillic and the last one a digit (which is script independent) (\u'0440'\u'0430'\u'0443'\u'0440'\u'040'\u'0031' [1]), therefore not even violating conventions prohibiting mixed-script labels. There is, of course, no ambiguity in the A-label form, although the authors quite properly point out that it is not user-friendly. By contrast, Section 1.1 talks about display of email addresses, including the local part ("in Punycode" [2]).=C2=A0 While a mail delivery server is free to create whatever aliases for a mailbox local part it likes, including "xn-t2bmh3a" or "123456", "george" or "example", in general converting a local part using the Punycode algorithm and displaying the result is prohibited by the EAI standards (and, incidentally, RFC5321).=C2=A0 More important, it will often lose information and is potentially very dangerous. (3) Arabic should not be confused with a strictly right-to-left writing system.=C2=A0 I am not aware of any such systems in wide use for contemporary languages today.=C2=A0 The problem is that numerals, whether written in European digits, Arabic or Arabic-Indic digits, Chinese (Han) digits, or many others, have been written left to right since that type of positional notation was invented and became widely used.=C2=A0 As a result, the scripts are referred to (in Unicode-speak) as "bidirectional" or "bidi" [3]. Their implications for domain names and IDNA are the subject of RFC 5893. (4) Multiple addresses for one user (and Section 4).=C2=A0 Keeping in mind that many people maintain a number of identities, and even multiple email addresses, for different purposes, I don't understand what point you are trying to make with this section. Many of us believe that users who have mailboxes whose names involve non-ASCII local parts and who engage in communications outside their primary language group will find it necessary to maintain either separate all-ASCII mailboxes or all-ASCII aliases to their primary mailboxes and to do so for a very long time.=C2=A0 That issue has been extensively analyzed and discussed but this document avoids that work, which is both a problem and an opportunity. (5) Section 2.1 asserts that email servers), implying all of them, store data (messages?) in relational databases.=C2=A0 That is simply false.=C2=A0 Some do; others don't.=C2=A0 Even for those that do, there may be a difference between Unicode-capable data storage and Unicode-capable keys or indexes.=C2=A0 There is also absolutely no requirement that any such system store Unicode strings encoded in UTF-8; many do not.=C2=A0=20 (6) There is a necessary difficulty with SMTPUTF8, which is that one cannot transmit a message with non-ASCII characters in addresses or headers to a system that does not support them. Final delivery systems should probably not accept messages unless they have reason to predict that the mail store will handle them _and_ that the user associated with the target mailbox will be able to retrieve them.=C2=A0 Since a user with an all-ASCII mailbox name might still receive a message with, e.g., a non-ASCII backward-pointing address in the envelope or headers, making that decision is not straightforward.=C2=A0 That leads to a strong case that, if one wants broad deployment of SMTPUTF8, the place to start is with the MUAs (including the Webmail systems) and associated POP and IMAP servers and clients.=C2=A0 The "to various extents" list in the first part of Section 3 is not particularly helpful in that regard. (7) Finally, this is an internationalization (i18n) problem as much as it is an email problem.=C2=A0 Terminology (and, where characters or code points are referred to, their precise identification) is very important because the alternative is typically a good deal of user confusion about what you are talking about and other impediments to making progress.=C2=A0 Saying "English" were you mean "Basic Latin Script" or "ASCII" is not helpful, especially given that 5321 local parts can include any ASCII character and that ASCII is not sufficient to write English.=C2=A0 Conversely, it appears that there are a few places where, correctly or incorrectly, you really do mean "English" when you say that.=C2=A0 Similarly, talking about one particular encoding when you mean "Unicode" is confusing and may be misleading.=C2=A0 RFC 6365 may give you a start on some of the issues. regards, =C2=A0 =C2=A0 john =C2=A0 ------------- [1] I recommend the authors have a look at RFC 5137. [2] Punycode is an encoding method, not a display format.=C2=A0 See RFC 5890, Section=C2=A0 2.3.4.=20 [3] http://unicode.org/reports/tr9/ _______________________________________________ IMA mailing list IMA@ietf.org https://www.ietf.org/mailman/listinfo/ima ------=_Part_287119_486004661.1476456866325 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
John / Tony,

=
>(3) Arabic should not = be confused with a strictly right-to-left writing system.  I am n= ot aware of any such systems in wide use for contemporary languages to= day.  The problem is that
> numerals, whether written in European digits, Arab= ic or Arabic-Indic digits, Chinese (Han) digits, or many o= thers, have been written left to right since that type of = positional notation was
> invented and became widely used.  As a result, the scri= pts are referred to (in Unicode-speak) as "bidirectional" or "bidi" [3= ].

Will change to say "bi= di".  

I= am very curious as to the "on the ground" implications of this.   I h= ave heard that there is some activity in setting up a test bed for EAI for = Arabic languages.   Is there anyone who can comment on real life probl= ems and issues?


>Their implications fo= r domain names and IDNA are the subject of RFC 5893.

Will cite.

 
Thanks,

Nalini Elkins<= br>Inside Products, Inc.
www.insidethestack.com
(831) 659-8360


________________________________
From: John C Klensin <klen= sin@jck.com>
To: "HANSEN, TONY L" <tony@att.com>; ima@ietf.org =
Sent: Sunday, October 9, 2016 7:57 PM
Subject: Re: [EAI] [IETF] Inte= rnationalized Email Internet Draft




--On Thursday, Octob= er 06, 2016 4:39 PM +0000 "HANSEN, TONY L"
<tony@att.com> wrote:
> I think getting deployment feedback from EAI is important, and> this draft is an excellent start.
>
> I'm not convinced= that section 1.2 describes a real problem.
> People do this all the = time today with various combinations of
> languages. Why is the combi= nation of Russian and Chinese any
> different? If you think it is, th= en please expand on the
> aspect that does make it more difficult.>
> I forwarded a number of nits to the authors.

Hi. = ; I was going to hold off until some later and more mature
version of th= is draft, but since Tony has commented, while I
believe the issues with = EAI deployment are important, I see
several problems with this draft, so= me of which were actually
discussed in the WG but appear to be ignored h= ere.  Perhaps more
important, it is seriously incomplete relative t= o issues that
have been discussed at great length in the EAI WG, at the = APEC
meeting on internationalized email in Beijing in October 2014,
t= he May 2015 workshop in Thailand, and elsewhere.  I strongly
sugges= t that, if there is going to be a discussion in Seoul,
this document is = in need of a great deal of work first.  Some of
those issues are:
(1) The so-called EAI standards, as listed in the Introduction,
ar= e about email envelope and header information presented
directly (e.g., = in UTF-8) as non-ASCII characters.  A good deal
of the document app= ears to address mail content information such
as textual message bodies,= in other scripts.  With the possible
exception of language selecti= on when a message is sent with the
same basic text in several languages = (multipart/alternative was
designed with that case in mind but have been= used in other
ways), we thought we solved that content problem with MIM= E in
1992.  If MIME is inadequate, the authors or others should
= produce a document explaining the issues and not confuse them
with EAI /= SMTPUTF8.  If it is adequate, then, like Tony
although perhaps for= different reasons, I don't see what Section
1.2 is doing here, what the= relevance of Section 3.2 is, and
several other statements should be exa= mined carefully to be sure
they are talking about addresses and/or heade= rs and not content.

(2) Within an address, there is, as the I-D poin= ts out and
consistent with RFC 5321, a local part and a domain part.&nbs= p; RFCs
6530 and 6531 make it quite clear (at least we thought they did)=
that they are handled differently.  For the domain part, the
ru= les are laid out in the IDNA2008 specs (RFC 5890ff).  Issues
about = look-alike characters have been extensively discussed and
written about = (even though some of us have questioned the
quality of some of that work= ).  It does not seem useful to me to
revisit those issues here, esp= ecially without reference to the
prior work and discussions or if some o= f the discussion here is
wrong or contains obvious omissions.  As a= n example from the
first paragraph of Section 6.1, Latin "c" (U+0063) an= d Cyrillic
"c" (U+0441) are typically written with identical graphemes, = but
are not on the list.    More important, while the "paypal"=
example with U+0430 substituted for "a" (U+0061) has been used
repea= tedly, including in a careful study in an article that is
not cited in t= his draft, it is possible to write "=D1=80=D0=B0=D1=83=D1=80=D0=B01"
wit= h the first five characters in Cyrillic and the last one a
digit (which = is script independent)
(\u'0440'\u'0430'\u'0443'\u'0440'\u'040'\u'0031' = [1]), therefore
not even violating conventions prohibiting mixed-script = labels.
There is, of course, no ambiguity in the A-label form, although<= br>the authors quite properly point out that it is not
user-friendly.
By contrast, Section 1.1 talks about display of email addresses,
in= cluding the local part ("in Punycode" [2]).  While a mail
delivery = server is free to create whatever aliases for a mailbox
local part it li= kes, including "xn-t2bmh3a" or "123456",
"george" or "example", in gener= al converting a local part using
the Punycode algorithm and displaying t= he result is prohibited
by the EAI standards (and, incidentally, RFC5321= ).  More
important, it will often lose information and is potential= ly
very dangerous.

(3) Arabic should not be confused with a stric= tly right-to-left
writing system.  I am not aware of any such syste= ms in wide use
for contemporary languages today.  The problem is th= at numerals,
whether written in European digits, Arabic or Arabic-Indic<= br>digits, Chinese (Han) digits, or many others, have been written
left = to right since that type of positional notation was
invented and became = widely used.  As a result, the scripts are
referred to (in Unicode-= speak) as "bidirectional" or "bidi" [3].
Their implications for domain n= ames and IDNA are the subject of
RFC 5893.

(4) Multiple addresses= for one user (and Section 4).  Keeping in
mind that many people ma= intain a number of identities, and even
multiple email addresses, for di= fferent purposes, I don't
understand what point you are trying to make w= ith this section.
Many of us believe that users who have mailboxes whose= names
involve non-ASCII local parts and who engage in communicationsoutside their primary language group will find it necessary to
maintain= either separate all-ASCII mailboxes or all-ASCII
aliases to their prima= ry mailboxes and to do so for a very long
time.  That issue has bee= n extensively analyzed and discussed
but this document avoids that work,= which is both a problem and
an opportunity.

(5) Section 2.1 asse= rts that email servers), implying all of
them, store data (messages?) in= relational databases.  That is
simply false.  Some do; others= don't.  Even for those that do,
there may be a difference between= Unicode-capable data storage
and Unicode-capable keys or indexes. = There is also absolutely
no requirement that any such system store Uni= code strings
encoded in UTF-8; many do not. 

(6) There is a= necessary difficulty with SMTPUTF8, which is that
one cannot transmit a= message with non-ASCII characters in
addresses or headers to a system t= hat does not support them.
Final delivery systems should probably not ac= cept messages
unless they have reason to predict that the mail store wil= l
handle them _and_ that the user associated with the target
mailbox = will be able to retrieve them.  Since a user with an
all-ASCII mail= box name might still receive a message with, e.g.,
a non-ASCII backward-= pointing address in the envelope or
headers, making that decision is not= straightforward.  That
leads to a strong case that, if one wants b= road deployment of
SMTPUTF8, the place to start is with the MUAs (includ= ing the
Webmail systems) and associated POP and IMAP servers and
clie= nts.  The "to various extents" list in the first part of
Section 3= is not particularly helpful in that regard.

(7) Finally, this is an= internationalization (i18n) problem as
much as it is an email problem.&= nbsp; Terminology (and, where
characters or code points are referred to,= their precise
identification) is very important because the alternative= is
typically a good deal of user confusion about what you are
talkin= g about and other impediments to making progress.  Saying
"English"= were you mean "Basic Latin Script" or "ASCII" is not
helpful, especiall= y given that 5321 local parts can include any
ASCII character and that A= SCII is not sufficient to write
English.  Conversely, it appears th= at there are a few places
where, correctly or incorrectly, you really do= mean "English"
when you say that.  Similarly, talking about one p= articular
encoding when you mean "Unicode" is confusing and may be
mi= sleading.  RFC 6365 may give you a start on some of the issues.
regards,
    john


  -------------
[1] I re= commend the authors have a look at RFC 5137.

[2] Punycode is an enco= ding method, not a display format.  See
RFC 5890, Section  2.3= .4.

[3] http://unicode.org/reports/tr9/


________________= _______________________________
IMA mailing list
IMA@ietf.org
http= s://www.ietf.org/mailman/listinfo/ima
------=_Part_287119_486004661.1476456866325-- From nobody Fri Oct 14 08:07:44 2016 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D806112982B for ; Fri, 14 Oct 2016 08:07:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id geuF-wmZueWJ for ; Fri, 14 Oct 2016 08:07:38 -0700 (PDT) Received: from nm3-vm1.bullet.mail.ne1.yahoo.com (nm3-vm1.bullet.mail.ne1.yahoo.com [98.138.91.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42075129790 for ; Fri, 14 Oct 2016 08:07:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1476457654; bh=FMuGvByRSBq//pLi77oYAmbncw/xPuPyFsqgEZEinkU=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=eM+PqhAszIxhE+wu2xWTJP0wFvTkjOpqSR0voLikiRvy8DnzxinrVk8cxxN+2ul+nzZnpa1pq0lZATV4bwKqQ85mst8dFep/39u52Sc2HML7BxA/fBZNhaVgm955EE6Xg0Po2fiiopZ2CPRC76ZkwL8n1l3FlUXU+bEesPUH0BF+bQHwRw7DoYS2dvioTgV4zo685Vj0mluhyTbEoEIVstG3RsKqo/DwAodH5A0vE+bwOpqyUh9U1gEI2yXtFT3aJpHVXeOH7gZrxO6W2SeajZU9nVQfJESGK4uaseNf1gHmVgCOqTZJPvwkqUL5IYNnKxDJZEdiwYLKHoY3tLIOuQ== Received: from [98.138.100.103] by nm3.bullet.mail.ne1.yahoo.com with NNFMP; 14 Oct 2016 15:07:34 -0000 Received: from [98.138.89.250] by tm102.bullet.mail.ne1.yahoo.com with NNFMP; 14 Oct 2016 15:07:34 -0000 Received: from [127.0.0.1] by omp1042.mail.ne1.yahoo.com with NNFMP; 14 Oct 2016 15:07:34 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 682703.58798.bm@omp1042.mail.ne1.yahoo.com X-YMail-OSG: 7QDby_YVM1nmM44JLJ5P1gpJY0utD3JBbwWOYny0W0z.4R90ENRCvymbxVeRD4G 5r2fSmO_m82chO6mVczBvM_OgkllVtnEv9bkZ2nccj98mBbwPyVcon2LGLQaqKTyf0roh68QV.v6 Hdkx6yvlJBT.vXcvFpNAxgTqRU_PZvs.rtU5Y95ggOBa3kGcIt0fsBiCb9BU_qQxgE9MqJ3vdaoN BjfxepE73fv7bJabIou6R9GWED2laN.6VZCz7OemV5cqrBkHTmyc60SjXlvexSi5ys9oUUBShPpV JGamKszc86.ylxLSze5CMDwi7mi2YmKhN6Q7mOq5HspVj7VeUhxjGMRvlunIBGoJfVgWfpgqqzww 7_mMhkI6XeVGCMpo8Unh55dXC3PwrilQizzCEGei_53QEqgGlIdCBUfh3gjFtRMutk23z5xG9513 GUQtI6jZioyPRxUAUY0qzEr_1rsaFUbPxNdlixffXwHUi.W.q6TTAlTmFKlnCGaPTWxNxrrJj4DF GH76wC2tXIdxVTq1XKFa2obd9rOg.0W7sOFXEUE_i3dYDPLc19pc- Received: from jws200028.mail.ne1.yahoo.com by sendmailws150.mail.ne1.yahoo.com; Fri, 14 Oct 2016 15:07:33 +0000; 1476457653.399 Date: Fri, 14 Oct 2016 15:07:17 +0000 (UTC) From: To: John C Klensin , "HANSEN, TONY L" , "ima@ietf.org" Message-ID: <2048473830.314096.1476457637592@mail.yahoo.com> In-Reply-To: References: <20161006055447.32573.qmail@pro-236-157.rediffmailpro.com> <9EC0EB65-9C58-43ED-9A80-1DA32C58E3E0@att.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_314095_1635529808.1476457637582" Archived-At: Cc: Harish Chowdhary Subject: [EAI] [IETF] Multiple Addresses [ was: Internationalized Email Internet Draft] X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: nalini.elkins@insidethestack.com List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 15:07:43 -0000 ------=_Part_314095_1635529808.1476457637582 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable John / Tony, >(4) Multiple addresses for one user (and Section 4).=C2=A0 Keeping in=C2= =A0mind that many people maintain a number of identities, and even=C2=A0mul= tiple email addresses, for different purposes, I >don't=C2=A0understand wha= t point you are trying to make with this section.=C2=A0 Sure. =C2=A0People have multiple email addresses for different reasons. =C2= =A0 The question was actually with aliases. =C2=A0Maybe it is not possible = to have all email consolidated to one box. For example, if I want to have two mailboxes: nalini@mymailserver.com and=C2=A0=E0=A4=A8=E0=A4=B2=E0=A4=BF=E0=A4=A8=E0=A5= =80@mymailserver.com (or=C2=A0=E0=A4=A8=E0=A4=B2=E0=A4=BF=E0=A4=A8=E0=A5=80= @[myidnserver].[myinternationaltld]) all come to one mailbox is that possib= le? =C2=A0 Should it be possible? I *think* people want that. =C2=A0 I think we will know as this all takes o= ff. >Many of us believe that users who have mailboxes whose names involve non-A= SCII local parts and who engage in communications outside their primary lan= guage group will find it >necessary to maintain either separate all-ASCII m= ailboxes or all-ASCII aliases to their primary mailboxes and to do so for a= very long time.=C2=A0 That issue has been extensively analyzed and >discus= sed but this document avoids that work, which is both a problem and an oppo= rtunity. Can you point me to some of that work? =C2=A0At the very least, we can cite= it & I can become familiar with it. =C2=A0 Then, let's see what real life = usage tells us about possible requirements in this area. =C2=A0 Thanks, Nalini Elkins Inside Products, Inc. www.insidethestack.com (831) 659-8360 ________________________________ From: John C Klensin To: "HANSEN, TONY L" ; ima@ietf.org=20 Sent: Sunday, October 9, 2016 7:57 PM Subject: Re: [EAI] [IETF] Internationalized Email Internet Draft =20 --On Thursday, October 06, 2016 4:39 PM +0000 "HANSEN, TONY L" wrote: > I think getting deployment feedback from EAI is important, and > this draft is an excellent start. >=20 > I'm not convinced that section 1.2 describes a real problem. > People do this all the time today with various combinations of > languages. Why is the combination of Russian and Chinese any > different? If you think it is, then please expand on the > aspect that does make it more difficult. >=20 > I forwarded a number of nits to the authors. Hi.=C2=A0 I was going to hold off until some later and more mature version of this draft, but since Tony has commented, while I believe the issues with EAI deployment are important, I see several problems with this draft, some of which were actually discussed in the WG but appear to be ignored here.=C2=A0 Perhaps more important, it is seriously incomplete relative to issues that have been discussed at great length in the EAI WG, at the APEC meeting on internationalized email in Beijing in October 2014, the May 2015 workshop in Thailand, and elsewhere.=C2=A0 I strongly suggest that, if there is going to be a discussion in Seoul, this document is in need of a great deal of work first.=C2=A0 Some of those issues are: (1) The so-called EAI standards, as listed in the Introduction, are about email envelope and header information presented directly (e.g., in UTF-8) as non-ASCII characters.=C2=A0 A good deal of the document appears to address mail content information such as textual message bodies, in other scripts.=C2=A0 With the possible exception of language selection when a message is sent with the same basic text in several languages (multipart/alternative was designed with that case in mind but have been used in other ways), we thought we solved that content problem with MIME in 1992.=C2=A0 If MIME is inadequate, the authors or others should produce a document explaining the issues and not confuse them with EAI / SMTPUTF8.=C2=A0 If it is adequate, then, like Tony although perhaps for different reasons, I don't see what Section 1.2 is doing here, what the relevance of Section 3.2 is, and several other statements should be examined carefully to be sure they are talking about addresses and/or headers and not content. (2) Within an address, there is, as the I-D points out and consistent with RFC 5321, a local part and a domain part.=C2=A0 RFCs 6530 and 6531 make it quite clear (at least we thought they did) that they are handled differently.=C2=A0 For the domain part, the rules are laid out in the IDNA2008 specs (RFC 5890ff).=C2=A0 Issues about look-alike characters have been extensively discussed and written about (even though some of us have questioned the quality of some of that work).=C2=A0 It does not seem useful to me to revisit those issues here, especially without reference to the prior work and discussions or if some of the discussion here is wrong or contains obvious omissions.=C2=A0 As an example from the first paragraph of Section 6.1, Latin "c" (U+0063) and Cyrillic "c" (U+0441) are typically written with identical graphemes, but are not on the list.=C2=A0 =C2=A0 More important, while the "paypal" example with U+0430 substituted for "a" (U+0061) has been used repeatedly, including in a careful study in an article that is not cited in this draft, it is possible to write "=D1=80=D0=B0=D1=83=D1=80= =D0=B01" with the first five characters in Cyrillic and the last one a digit (which is script independent) (\u'0440'\u'0430'\u'0443'\u'0440'\u'040'\u'0031' [1]), therefore not even violating conventions prohibiting mixed-script labels. There is, of course, no ambiguity in the A-label form, although the authors quite properly point out that it is not user-friendly. By contrast, Section 1.1 talks about display of email addresses, including the local part ("in Punycode" [2]).=C2=A0 While a mail delivery server is free to create whatever aliases for a mailbox local part it likes, including "xn-t2bmh3a" or "123456", "george" or "example", in general converting a local part using the Punycode algorithm and displaying the result is prohibited by the EAI standards (and, incidentally, RFC5321).=C2=A0 More important, it will often lose information and is potentially very dangerous. (3) Arabic should not be confused with a strictly right-to-left writing system.=C2=A0 I am not aware of any such systems in wide use for contemporary languages today.=C2=A0 The problem is that numerals, whether written in European digits, Arabic or Arabic-Indic digits, Chinese (Han) digits, or many others, have been written left to right since that type of positional notation was invented and became widely used.=C2=A0 As a result, the scripts are referred to (in Unicode-speak) as "bidirectional" or "bidi" [3]. Their implications for domain names and IDNA are the subject of RFC 5893. (4) Multiple addresses for one user (and Section 4).=C2=A0 Keeping in mind that many people maintain a number of identities, and even multiple email addresses, for different purposes, I don't understand what point you are trying to make with this section. Many of us believe that users who have mailboxes whose names involve non-ASCII local parts and who engage in communications outside their primary language group will find it necessary to maintain either separate all-ASCII mailboxes or all-ASCII aliases to their primary mailboxes and to do so for a very long time.=C2=A0 That issue has been extensively analyzed and discussed but this document avoids that work, which is both a problem and an opportunity. (5) Section 2.1 asserts that email servers), implying all of them, store data (messages?) in relational databases.=C2=A0 That is simply false.=C2=A0 Some do; others don't.=C2=A0 Even for those that do, there may be a difference between Unicode-capable data storage and Unicode-capable keys or indexes.=C2=A0 There is also absolutely no requirement that any such system store Unicode strings encoded in UTF-8; many do not.=C2=A0=20 (6) There is a necessary difficulty with SMTPUTF8, which is that one cannot transmit a message with non-ASCII characters in addresses or headers to a system that does not support them. Final delivery systems should probably not accept messages unless they have reason to predict that the mail store will handle them _and_ that the user associated with the target mailbox will be able to retrieve them.=C2=A0 Since a user with an all-ASCII mailbox name might still receive a message with, e.g., a non-ASCII backward-pointing address in the envelope or headers, making that decision is not straightforward.=C2=A0 That leads to a strong case that, if one wants broad deployment of SMTPUTF8, the place to start is with the MUAs (including the Webmail systems) and associated POP and IMAP servers and clients.=C2=A0 The "to various extents" list in the first part of Section 3 is not particularly helpful in that regard. (7) Finally, this is an internationalization (i18n) problem as much as it is an email problem.=C2=A0 Terminology (and, where characters or code points are referred to, their precise identification) is very important because the alternative is typically a good deal of user confusion about what you are talking about and other impediments to making progress.=C2=A0 Saying "English" were you mean "Basic Latin Script" or "ASCII" is not helpful, especially given that 5321 local parts can include any ASCII character and that ASCII is not sufficient to write English.=C2=A0 Conversely, it appears that there are a few places where, correctly or incorrectly, you really do mean "English" when you say that.=C2=A0 Similarly, talking about one particular encoding when you mean "Unicode" is confusing and may be misleading.=C2=A0 RFC 6365 may give you a start on some of the issues. regards, =C2=A0 =C2=A0 john =C2=A0 ------------- [1] I recommend the authors have a look at RFC 5137. [2] Punycode is an encoding method, not a display format.=C2=A0 See RFC 5890, Section=C2=A0 2.3.4.=20 [3] http://unicode.org/reports/tr9/ _______________________________________________ IMA mailing list IMA@ietf.org https://www.ietf.org/mailman/listinfo/ima ------=_Part_314095_1635529808.1476457637582 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
John / Tony,

=
>(4) Multiple addresse= s for one user (and Section 4).  Keeping in mind that many people= maintain a number of identities, and even multiple email addresses, f= or different purposes, I >don't understand what point you are tryin= g to make with this section. 

= Sure.  People have multiple email addresses for different reasons. &nb= sp; The question was actually with aliases.  Maybe it is not pos= sible to have all email consolidated to one box.
For example, if I want to have two mailboxes:

nalini@mymailserver.com and =E0=A4=A8=E0= =A4=B2=E0=A4=BF=E0=A4=A8=E0=A5=80@mymailserver.com (or = =E0=A4=A8=E0=A4=B2=E0=A4=BF=E0=A4=A8=E0=A5=80@[myidnserver].[myinternationa= ltld]) all come to one mailbox is that possible?   Should it be possib= le?

I *think= * people want that.   I think we will know as this all takes off.


>= Many of us believe that users who have mailboxes whose names involve non-AS= CII local parts and who engage in communications outside their primary lang= uage group will find it >necessary to maintain either separate all-ASCII= mailboxes or all-ASCII aliases to their primary mailboxes and to do so for= a very long time.  That issue has been extensively analyzed and >d= iscussed but this document avoids that work, which is both a problem and an= opportunity.

Can you point me to s= ome of that work?  At the very least, we can cite it & I can becom= e familiar with it.   Then, let's see what real life usage tells us ab= out possible requirements in this area.

 
Thanks,

N= alini Elkins
Inside Products, Inc.
www.insidethestack.com
(831) 65= 9-8360



________________________________
From: John C Kle= nsin <klensin@jck.com>
To: "HANSEN, TONY L" <tony@att.com>; = ima@ietf.org
Sent: Sunday, October 9, 2016 7:57 PM
Subject: Re: [EAI= ] [IETF] Internationalized Email Internet Draft




--On Th= ursday, October 06, 2016 4:39 PM +0000 "HANSEN, TONY L"
<tony@att.com= > wrote:

> I think getting deployment feedback from EAI is imp= ortant, and
> this draft is an excellent start.
>
> I'm = not convinced that section 1.2 describes a real problem.
> People do = this all the time today with various combinations of
> languages. Why= is the combination of Russian and Chinese any
> different? If you th= ink it is, then please expand on the
> aspect that does make it more = difficult.
>
> I forwarded a number of nits to the authors.
Hi.  I was going to hold off until some later and more mature
= version of this draft, but since Tony has commented, while I
believe the= issues with EAI deployment are important, I see
several problems with t= his draft, some of which were actually
discussed in the WG but appear to= be ignored here.  Perhaps more
important, it is seriously incomple= te relative to issues that
have been discussed at great length in the EA= I WG, at the APEC
meeting on internationalized email in Beijing in Octob= er 2014,
the May 2015 workshop in Thailand, and elsewhere.  I stron= gly
suggest that, if there is going to be a discussion in Seoul,
this= document is in need of a great deal of work first.  Some of
those = issues are:

(1) The so-called EAI standards, as listed in the Introd= uction,
are about email envelope and header information presented
dir= ectly (e.g., in UTF-8) as non-ASCII characters.  A good deal
of the= document appears to address mail content information such
as textual me= ssage bodies, in other scripts.  With the possible
exception of lan= guage selection when a message is sent with the
same basic text in sever= al languages (multipart/alternative was
designed with that case in mind = but have been used in other
ways), we thought we solved that content pro= blem with MIME in
1992.  If MIME is inadequate, the authors or othe= rs should
produce a document explaining the issues and not confuse them<= br>with EAI / SMTPUTF8.  If it is adequate, then, like Tony
althoug= h perhaps for different reasons, I don't see what Section
1.2 is doing h= ere, what the relevance of Section 3.2 is, and
several other statements = should be examined carefully to be sure
they are talking about addresses= and/or headers and not content.

(2) Within an address, there is, as= the I-D points out and
consistent with RFC 5321, a local part and a dom= ain part.  RFCs
6530 and 6531 make it quite clear (at least we thou= ght they did)
that they are handled differently.  For the domain pa= rt, the
rules are laid out in the IDNA2008 specs (RFC 5890ff).  Iss= ues
about look-alike characters have been extensively discussed and
w= ritten about (even though some of us have questioned the
quality of some= of that work).  It does not seem useful to me to
revisit those iss= ues here, especially without reference to the
prior work and discussions= or if some of the discussion here is
wrong or contains obvious omission= s.  As an example from the
first paragraph of Section 6.1, Latin "c= " (U+0063) and Cyrillic
"c" (U+0441) are typically written with identica= l graphemes, but
are not on the list.    More important, while= the "paypal"
example with U+0430 substituted for "a" (U+0061) has been = used
repeatedly, including in a careful study in an article that is
n= ot cited in this draft, it is possible to write "=D1=80=D0=B0=D1=83=D1=80= =D0=B01"
with the first five characters in Cyrillic and the last one adigit (which is script independent)
(\u'0440'\u'0430'\u'0443'\u'0440'\= u'040'\u'0031' [1]), therefore
not even violating conventions prohibitin= g mixed-script labels.
There is, of course, no ambiguity in the A-label = form, although
the authors quite properly point out that it is not
us= er-friendly.

By contrast, Section 1.1 talks about display of email a= ddresses,
including the local part ("in Punycode" [2]).  While a ma= il
delivery server is free to create whatever aliases for a mailbox
l= ocal part it likes, including "xn-t2bmh3a" or "123456",
"george" or "exa= mple", in general converting a local part using
the Punycode algorithm a= nd displaying the result is prohibited
by the EAI standards (and, incide= ntally, RFC5321).  More
important, it will often lose information a= nd is potentially
very dangerous.

(3) Arabic should not be confus= ed with a strictly right-to-left
writing system.  I am not aware of= any such systems in wide use
for contemporary languages today.  Th= e problem is that numerals,
whether written in European digits, Arabic o= r Arabic-Indic
digits, Chinese (Han) digits, or many others, have been w= ritten
left to right since that type of positional notation was
inven= ted and became widely used.  As a result, the scripts are
referred = to (in Unicode-speak) as "bidirectional" or "bidi" [3].
Their implicatio= ns for domain names and IDNA are the subject of
RFC 5893.

(4) Mul= tiple addresses for one user (and Section 4).  Keeping in
mind that= many people maintain a number of identities, and even
multiple email ad= dresses, for different purposes, I don't
understand what point you are t= rying to make with this section.
Many of us believe that users who have = mailboxes whose names
involve non-ASCII local parts and who engage in co= mmunications
outside their primary language group will find it necessary= to
maintain either separate all-ASCII mailboxes or all-ASCII
aliases= to their primary mailboxes and to do so for a very long
time.  Tha= t issue has been extensively analyzed and discussed
but this document av= oids that work, which is both a problem and
an opportunity.

(5) S= ection 2.1 asserts that email servers), implying all of
them, store data= (messages?) in relational databases.  That is
simply false.  = Some do; others don't.  Even for those that do,
there may be a dif= ference between Unicode-capable data storage
and Unicode-capable keys or= indexes.  There is also absolutely
no requirement that any such s= ystem store Unicode strings
encoded in UTF-8; many do not. 
(6) There is a necessary difficulty with SMTPUTF8, which is that
one ca= nnot transmit a message with non-ASCII characters in
addresses or header= s to a system that does not support them.
Final delivery systems should = probably not accept messages
unless they have reason to predict that the= mail store will
handle them _and_ that the user associated with the tar= get
mailbox will be able to retrieve them.  Since a user with anall-ASCII mailbox name might still receive a message with, e.g.,
a non-= ASCII backward-pointing address in the envelope or
headers, making that = decision is not straightforward.  That
leads to a strong case that,= if one wants broad deployment of
SMTPUTF8, the place to start is with t= he MUAs (including the
Webmail systems) and associated POP and IMAP serv= ers and
clients.  The "to various extents" list in the first part = of
Section 3 is not particularly helpful in that regard.

(7) Fina= lly, this is an internationalization (i18n) problem as
much as it is an = email problem.  Terminology (and, where
characters or code points a= re referred to, their precise
identification) is very important because = the alternative is
typically a good deal of user confusion about what yo= u are
talking about and other impediments to making progress.  Sayi= ng
"English" were you mean "Basic Latin Script" or "ASCII" is not
hel= pful, especially given that 5321 local parts can include any
ASCII chara= cter and that ASCII is not sufficient to write
English.  Conversely= , it appears that there are a few places
where, correctly or incorrectly= , you really do mean "English"
when you say that.  Similarly, talk= ing about one particular
encoding when you mean "Unicode" is confusing a= nd may be
misleading.  RFC 6365 may give you a start on some of the= issues.

regards,
    john


  ----------= ---
[1] I recommend the authors have a look at RFC 5137.

[2] Puny= code is an encoding method, not a display format.  See
RFC 5890, Se= ction  2.3.4.

[3] http://unicode.org/reports/tr9/


_= ______________________________________________
IMA mailing list
IMA@i= etf.org
https://www.ietf.org/mailman/listinfo/ima
------=_Part_314095_1635529808.1476457637582-- From nobody Fri Oct 14 08:09:02 2016 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A96C129838 for ; Fri, 14 Oct 2016 08:09:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ASbxRGxRwQTt for ; Fri, 14 Oct 2016 08:08:55 -0700 (PDT) Received: from mx2.yitter.info (mx2.yitter.info [IPv6:2600:3c03::f03c:91ff:fedf:cfab]) by ietfa.amsl.com (Postfix) with ESMTP id B6244129760 for ; Fri, 14 Oct 2016 08:08:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx2.yitter.info (Postfix) with ESMTP id C03ED1125A for ; Fri, 14 Oct 2016 15:08:51 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx2.yitter.info ([127.0.0.1]) by localhost (mx2.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LZpEaWSdnxX8 for ; Fri, 14 Oct 2016 15:08:51 +0000 (UTC) Received: from mx2.yitter.info (192-0-220-231.cpe.teksavvy.com [192.0.220.231]) by mx2.yitter.info (Postfix) with ESMTPSA id F1CCD11249 for ; Fri, 14 Oct 2016 15:08:50 +0000 (UTC) Date: Fri, 14 Oct 2016 11:08:50 -0400 From: Andrew Sullivan To: ima@ietf.org Message-ID: <20161014150850.GA43040@mx2.yitter.info> References: <20161006055447.32573.qmail@pro-236-157.rediffmailpro.com> <9EC0EB65-9C58-43ED-9A80-1DA32C58E3E0@att.com> <1600128477.303347.1476456552432@mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1600128477.303347.1476456552432@mail.yahoo.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [EAI] [IETF] Display of Email Addresses [was: Internationalized Email Internet Draft] X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 15:09:01 -0000 On Fri, Oct 14, 2016 at 02:49:12PM +0000, nalini.elkins@insidethestack.com wrote: > This is a very interesting problem.   We are hoping to do some kind of spreadsheet or other visual where we can show what happens with a number of mail servers. I think that effort has already been undertaken by the "Universal Acceptance Steering Group" over in ICANN. A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Fri Oct 14 08:17:39 2016 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CE90129760 for ; Fri, 14 Oct 2016 08:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ZqMcdtaCJ4B for ; Fri, 14 Oct 2016 08:17:33 -0700 (PDT) Received: from nm24-vm0.bullet.mail.ne1.yahoo.com (nm24-vm0.bullet.mail.ne1.yahoo.com [98.138.90.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF352129527 for ; Fri, 14 Oct 2016 08:17:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1476458252; bh=Npz+W6dOX0BRpixvEWSViDYVeFnb4VvYm6iXgh5suU0=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=Id7JrYUkidLIbky98NP21ME3aj8rLXUS+RN8XhDgiL5G7+uLqSS6vQ5zpMY5bbAPQ55aVgBnv3kev3l+v89TbZGRQ89VNjkjJ/9Ultm5MbX1ivvlPRyv8fmigsojCdar0MmpRd1RI465zHfRrnKgAt2dyrQ+wBAP/PJJHVgxC99L09G+Wr2YzoRrMyO7Q6geMql7myP0um22E4EUGrvlSg/iWeYnN9lMleHDwlrX+G4ac8/cpA+jEMnpCmljnw3VNTHxeICP5t4UzsZpnhKKP8Vvlo1gGJsQCXsLhmMs7bNoUTmEqMAS5niYzT9eQPKOAOoXr8cPMCbiVKmcpW9B5A== Received: from [98.138.226.177] by nm24.bullet.mail.ne1.yahoo.com with NNFMP; 14 Oct 2016 15:17:32 -0000 Received: from [98.138.87.9] by tm12.bullet.mail.ne1.yahoo.com with NNFMP; 14 Oct 2016 15:17:32 -0000 Received: from [127.0.0.1] by omp1009.mail.ne1.yahoo.com with NNFMP; 14 Oct 2016 15:17:32 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 63521.73808.bm@omp1009.mail.ne1.yahoo.com X-YMail-OSG: Zw9Si70VM1lcoM6FGCfzdQB5aaUNRHmstqM7GnIdfy.EV9SXA08a43Mf7e7Y3jt P61dhzWBj6OXDAKDq1fbDaiGoqvECl7mizp9DlfUHkCa44OC1DVG3iSSl0CYX9vkk0rGehiFSB_i 6yljaj14JN.ZxUqZvAgCobdLpYB3zJhTiGE554qssfhrCbeu7BjLRaHFe16.7GV7PP4qkmDZVU0o d.0FT3GiSz0See5.mX6kBONCfkFBM5_MFr6Z.M7hiyAlO9Qq43KOiQlIBTXhm0sMUq0uxHqowWu. QpQZS6i4O1jf.uYUCmKi2Xy5uJvvJ6FI3akMnAhnuYlpkmFYx1mSxGP9phdwlw9l4ki1SGZP4i1y vSrlKwxwJp2NQh6l5mpqV1s7iLlO66XqLMT.prmDR5ofirEj3Nk9NrGmrtgLGQWiu_NJFv2UEUMM GS8S8gaVhoY1P4CoqB3rGtSkvs9ZXIFskb7.z5iQ9NZIQ.adeNVMS71h4i6gFuoOHnsU0ZRGE.oT LvE_.RNW_15uDcZkgj9VO7t7HXXKHjb6cPGVVZsYq9C6gjUpB3Lw- Received: from jws200109.mail.ne1.yahoo.com by sendmailws142.mail.ne1.yahoo.com; Fri, 14 Oct 2016 15:17:31 +0000; 1476458251.662 Date: Fri, 14 Oct 2016 15:17:30 +0000 (UTC) From: To: John C Klensin , "HANSEN, TONY L" , "ima@ietf.org" Message-ID: <835182073.326693.1476458250633@mail.yahoo.com> In-Reply-To: References: <20161006055447.32573.qmail@pro-236-157.rediffmailpro.com> <9EC0EB65-9C58-43ED-9A80-1DA32C58E3E0@att.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_326692_104934480.1476458250628" Archived-At: Cc: Harish Chowdhary Subject: [EAI] [IETF] Relational Databases: UTF8 [was: Internationalized Email Internet Draft] X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: nalini.elkins@insidethestack.com List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 15:17:38 -0000 ------=_Part_326692_104934480.1476458250628 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable John / Tony, >(5) Section 2.1 asserts that email servers), implying all of=C2=A0them, st= ore data (messages?) in relational databases.=C2=A0 That is=C2=A0simply fal= se.=C2=A0 Some do; others don't.=C2=A0 Even for those that do,=C2=A0there m= ay be a difference between Unicode-capable >data storage=C2=A0and Unicode-c= apable keys or indexes.=C2=A0 There is also absolutely=C2=A0no requirement = that any such system store Unicode strings=C2=A0encoded in UTF-8; many do n= ot.=C2=A0=C2=A0 This actually came from my own operational experience in implementing an IE= A capable email server. =C2=A0 Will definitely change the wording to not im= ply that ALL email servers store in relational databases or store in UTF-8.= =C2=A0 I can see that is not a requirement. But, the problem that I had was with storing the user name, domain name, ma= tching, etc. =C2=A0 Not the messages. =C2=A0 It was totally a problem that = I ran into that the back end (whatever knows about the mailbox) had a probl= em with storing and matching user names & doing the DNS queries. Let me think about how to re-write this. =C2=A0 We may, in the end, want to= do some Best Practices kind of things so that people do not struggle for q= uite as long as I did! =C2=A0Thanks, Nalini ElkinsInside Products, Inc.www.insidethestack.com(831) 659-8360 From: John C Klensin To: "HANSEN, TONY L" ; ima@ietf.org=20 Sent: Sunday, October 9, 2016 7:57 PM Subject: Re: [EAI] [IETF] Internationalized Email Internet Draft =20 --On Thursday, October 06, 2016 4:39 PM +0000 "HANSEN, TONY L" wrote: > I think getting deployment feedback from EAI is important, and > this draft is an excellent start. >=20 > I'm not convinced that section 1.2 describes a real problem. > People do this all the time today with various combinations of > languages. Why is the combination of Russian and Chinese any > different? If you think it is, then please expand on the > aspect that does make it more difficult. >=20 > I forwarded a number of nits to the authors. Hi.=C2=A0 I was going to hold off until some later and more mature version of this draft, but since Tony has commented, while I believe the issues with EAI deployment are important, I see several problems with this draft, some of which were actually discussed in the WG but appear to be ignored here.=C2=A0 Perhaps more important, it is seriously incomplete relative to issues that have been discussed at great length in the EAI WG, at the APEC meeting on internationalized email in Beijing in October 2014, the May 2015 workshop in Thailand, and elsewhere.=C2=A0 I strongly suggest that, if there is going to be a discussion in Seoul, this document is in need of a great deal of work first.=C2=A0 Some of those issues are: (1) The so-called EAI standards, as listed in the Introduction, are about email envelope and header information presented directly (e.g., in UTF-8) as non-ASCII characters.=C2=A0 A good deal of the document appears to address mail content information such as textual message bodies, in other scripts.=C2=A0 With the possible exception of language selection when a message is sent with the same basic text in several languages (multipart/alternative was designed with that case in mind but have been used in other ways), we thought we solved that content problem with MIME in 1992.=C2=A0 If MIME is inadequate, the authors or others should produce a document explaining the issues and not confuse them with EAI / SMTPUTF8.=C2=A0 If it is adequate, then, like Tony although perhaps for different reasons, I don't see what Section 1.2 is doing here, what the relevance of Section 3.2 is, and several other statements should be examined carefully to be sure they are talking about addresses and/or headers and not content. (2) Within an address, there is, as the I-D points out and consistent with RFC 5321, a local part and a domain part.=C2=A0 RFCs 6530 and 6531 make it quite clear (at least we thought they did) that they are handled differently.=C2=A0 For the domain part, the rules are laid out in the IDNA2008 specs (RFC 5890ff).=C2=A0 Issues about look-alike characters have been extensively discussed and written about (even though some of us have questioned the quality of some of that work).=C2=A0 It does not seem useful to me to revisit those issues here, especially without reference to the prior work and discussions or if some of the discussion here is wrong or contains obvious omissions.=C2=A0 As an example from the first paragraph of Section 6.1, Latin "c" (U+0063) and Cyrillic "c" (U+0441) are typically written with identical graphemes, but are not on the list.=C2=A0 =C2=A0 More important, while the "paypal" example with U+0430 substituted for "a" (U+0061) has been used repeatedly, including in a careful study in an article that is not cited in this draft, it is possible to write "=D1=80=D0=B0=D1=83=D1=80= =D0=B01" with the first five characters in Cyrillic and the last one a digit (which is script independent) (\u'0440'\u'0430'\u'0443'\u'0440'\u'040'\u'0031' [1]), therefore not even violating conventions prohibiting mixed-script labels. There is, of course, no ambiguity in the A-label form, although the authors quite properly point out that it is not user-friendly. By contrast, Section 1.1 talks about display of email addresses, including the local part ("in Punycode" [2]).=C2=A0 While a mail delivery server is free to create whatever aliases for a mailbox local part it likes, including "xn-t2bmh3a" or "123456", "george" or "example", in general converting a local part using the Punycode algorithm and displaying the result is prohibited by the EAI standards (and, incidentally, RFC5321).=C2=A0 More important, it will often lose information and is potentially very dangerous. (3) Arabic should not be confused with a strictly right-to-left writing system.=C2=A0 I am not aware of any such systems in wide use for contemporary languages today.=C2=A0 The problem is that numerals, whether written in European digits, Arabic or Arabic-Indic digits, Chinese (Han) digits, or many others, have been written left to right since that type of positional notation was invented and became widely used.=C2=A0 As a result, the scripts are referred to (in Unicode-speak) as "bidirectional" or "bidi" [3]. Their implications for domain names and IDNA are the subject of RFC 5893. (4) Multiple addresses for one user (and Section 4).=C2=A0 Keeping in mind that many people maintain a number of identities, and even multiple email addresses, for different purposes, I don't understand what point you are trying to make with this section. Many of us believe that users who have mailboxes whose names involve non-ASCII local parts and who engage in communications outside their primary language group will find it necessary to maintain either separate all-ASCII mailboxes or all-ASCII aliases to their primary mailboxes and to do so for a very long time.=C2=A0 That issue has been extensively analyzed and discussed but this document avoids that work, which is both a problem and an opportunity. (5) Section 2.1 asserts that email servers), implying all of them, store data (messages?) in relational databases.=C2=A0 That is simply false.=C2=A0 Some do; others don't.=C2=A0 Even for those that do, there may be a difference between Unicode-capable data storage and Unicode-capable keys or indexes.=C2=A0 There is also absolutely no requirement that any such system store Unicode strings encoded in UTF-8; many do not.=C2=A0=20 (6) There is a necessary difficulty with SMTPUTF8, which is that one cannot transmit a message with non-ASCII characters in addresses or headers to a system that does not support them. Final delivery systems should probably not accept messages unless they have reason to predict that the mail store will handle them _and_ that the user associated with the target mailbox will be able to retrieve them.=C2=A0 Since a user with an all-ASCII mailbox name might still receive a message with, e.g., a non-ASCII backward-pointing address in the envelope or headers, making that decision is not straightforward.=C2=A0 That leads to a strong case that, if one wants broad deployment of SMTPUTF8, the place to start is with the MUAs (including the Webmail systems) and associated POP and IMAP servers and clients.=C2=A0 The "to various extents" list in the first part of Section 3 is not particularly helpful in that regard. (7) Finally, this is an internationalization (i18n) problem as much as it is an email problem.=C2=A0 Terminology (and, where characters or code points are referred to, their precise identification) is very important because the alternative is typically a good deal of user confusion about what you are talking about and other impediments to making progress.=C2=A0 Saying "English" were you mean "Basic Latin Script" or "ASCII" is not helpful, especially given that 5321 local parts can include any ASCII character and that ASCII is not sufficient to write English.=C2=A0 Conversely, it appears that there are a few places where, correctly or incorrectly, you really do mean "English" when you say that.=C2=A0 Similarly, talking about one particular encoding when you mean "Unicode" is confusing and may be misleading.=C2=A0 RFC 6365 may give you a start on some of the issues. regards, =C2=A0 =C2=A0 john =C2=A0 ------------- [1] I recommend the authors have a look at RFC 5137. [2] Punycode is an encoding method, not a display format.=C2=A0 See RFC 5890, Section=C2=A0 2.3.4.=20 [3] http://unicode.org/reports/tr9/ _______________________________________________ IMA mailing list IMA@ietf.org https://www.ietf.org/mailman/listinfo/ima =20 ------=_Part_326692_104934480.1476458250628 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
John / Tony,

>(5) Section 2.1 asserts that email servers), implying= all of them, s= tore data (messages?) in relational databases.  That is simply false.  Some do; = others don't.  Even for those that do, there may be a difference between Unicode-capa= ble >data storage and Unicode-capable keys or indexes.  There is also absolutely&n= bsp;no requirement t= hat any such system store Unicode strings encoded in UTF-8; many do not.  

This actually came from my own operational exp= erience in implementing an IEA capable email server.   Will definitely= change the wording to not imply that ALL email servers store in relational= databases or store in UTF-8.   I can see that is not a requirement.

But, the problem t= hat I had was with storing the user name, domain name, matching, etc.  = ; Not the messages.   It was totally a problem that I ran into that th= e back end (whatever knows about the mailbox) had a problem with storing an= d matching user names & doing the DNS queries.

Let me think about how to re-write this. &nbs= p; We may, in the end, want to do some Best Practices kind of things so tha= t people do not struggle for quite as long as I did!

<= div>
 
Thanks,<= div id=3D"yui_3_16_0_ym19_1_1476456872541_39195">
Nalini Elkins
Inside Products, Inc.
www.insidethest= ack.com
(831) 659-83= 60


From: John C Klensin <klensin@jck.com>
To: "HANSEN, TONY L" <tony@at= t.com>; ima@ietf.org
Sent: Sunday, October 9, 2016 7:57 PM
Subject: Re: [EAI] [IETF] Internationalized Email Intern= et Draft



--On Thursday, October 06, 2016 4:39 PM +0000 "HA= NSEN, TONY L"
<tony@att.com> wrote:

> I think getting deployment feedback from= EAI is important, and
> this draft is an excellent st= art.
>
> I'm not convinced that = section 1.2 describes a real problem.
> People do this= all the time today with various combinations of
> lan= guages. Why is the combination of Russian and Chinese any
> different? If you think it is, then please expand on the
> aspect that does make it more difficult.
> =
> I forwarded a number of nits to the authors.

Hi.  I was going to hold off until some= later and more mature
version of this draft, but since T= ony has commented, while I
believe the issues with EAI de= ployment are important, I see
several problems with this = draft, some of which were actually
discussed in the WG bu= t appear to be ignored here.  Perhaps more
important= , it is seriously incomplete relative to issues that
have= been discussed at great length in the EAI WG, at the APEC
meeting on internationalized email in Beijing in October 2014,
the May 2015 workshop in Thailand, and elsewhere.  I strongl= y
suggest that, if there is going to be a discussion in S= eoul,
this document is in need of a great deal of work fi= rst.  Some of
those issues are:
(1) The so-called EAI standards, as listed in the Introduc= tion,
are about email envelope and header information pre= sented
directly (e.g., in UTF-8) as non-ASCII characters.=   A good deal
of the document appears to address mai= l content information such
as textual message bodies, in = other scripts.  With the possible
exception of langu= age selection when a message is sent with the
same basic = text in several languages (multipart/alternative was
desi= gned with that case in mind but have been used in other
w= ays), we thought we solved that content problem with MIME in
1992.  If MIME is inadequate, the authors or others should
produce a document explaining the issues and not confuse themwith EAI / SMTPUTF8.  If it is adequate, then, like To= ny
although perhaps for different reasons, I don't see wh= at Section
1.2 is doing here, what the relevance of Secti= on 3.2 is, and
several other statements should be examine= d carefully to be sure
they are talking about addresses a= nd/or headers and not content.

(2) Wit= hin an address, there is, as the I-D points out and
consi= stent with RFC 5321, a local part and a domain part.  RFCs
6530 and 6531 make it quite clear (at least we thought they did)
that they are handled differently.  For the domain part= , the
rules are laid out in the IDNA2008 specs (RFC 5890f= f).  Issues
about look-alike characters have been ex= tensively discussed and
written about (even though some o= f us have questioned the
quality of some of that work).&n= bsp; It does not seem useful to me to
revisit those issue= s here, especially without reference to the
prior work an= d discussions or if some of the discussion here is
wrong = or contains obvious omissions.  As an example from the
first paragraph of Section 6.1, Latin "c" (U+0063) and Cyrillic
"c" (U+0441) are typically written with identical graphemes, but<= br clear=3D"none">are not on the list.    More important, while t= he "paypal"
example with U+0430 substituted for "a" (U+00= 61) has been used
repeatedly, including in a careful stud= y in an article that is
not cited in this draft, it is po= ssible to write "=D1=80=D0=B0=D1=83=D1=80=D0=B01"
with th= e first five characters in Cyrillic and the last one a
di= git (which is script independent)
(\u'0440'\u'0430'\u'044= 3'\u'0440'\u'040'\u'0031' [1]), therefore
not even violat= ing conventions prohibiting mixed-script labels.
There is= , of course, no ambiguity in the A-label form, although
t= he authors quite properly point out that it is not
user-f= riendly.

By contrast, Section 1.1 talk= s about display of email addresses,
including the local p= art ("in Punycode" [2]).  While a mail
delivery serv= er is free to create whatever aliases for a mailbox
local= part it likes, including "xn-t2bmh3a" or "123456",
"geor= ge" or "example", in general converting a local part using
the Punycode algorithm and displaying the result is prohibited
by the EAI standards (and, incidentally, RFC5321).  More
important, it will often lose information and is potentially=
very dangerous.

(3)= Arabic should not be confused with a strictly right-to-left
writing system.  I am not aware of any such systems in wide usefor contemporary languages today.  The problem is that= numerals,
whether written in European digits, Arabic or = Arabic-Indic
digits, Chinese (Han) digits, or many others= , have been written
left to right since that type of posi= tional notation was
invented and became widely used. = ; As a result, the scripts are
referred to (in Unicode-sp= eak) as "bidirectional" or "bidi" [3].
Their implications= for domain names and IDNA are the subject of
RFC 5893.
(4) Multiple addresses for one user (an= d Section 4).  Keeping in
mind that many people main= tain a number of identities, and even
multiple email addr= esses, for different purposes, I don't
understand what po= int you are trying to make with this section.
Many of us = believe that users who have mailboxes whose names
involve= non-ASCII local parts and who engage in communications
o= utside their primary language group will find it necessary to
maintain either separate all-ASCII mailboxes or all-ASCII
aliases to their primary mailboxes and to do so for a very long
time.  That issue has been extensively analyzed and discu= ssed
but this document avoids that work, which is both a = problem and
an opportunity.

(5) Section 2.1 asserts that email servers), implying all of
them, store data (messages?) in relational databases.  T= hat is
simply false.  Some do; others don't.  = Even for those that do,
there may be a difference between= Unicode-capable data storage
and Unicode-capable keys or= indexes.  There is also absolutely
no requirement = that any such system store Unicode strings
encoded in UTF= -8; many do not. 

(6) There is a= necessary difficulty with SMTPUTF8, which is that
one ca= nnot transmit a message with non-ASCII characters in
addr= esses or headers to a system that does not support them.
= Final delivery systems should probably not accept messages
unless they have reason to predict that the mail store will
handle them _and_ that the user associated with the target
mailbox will be able to retrieve them.  Since a user with anall-ASCII mailbox name might still receive a message with, = e.g.,
a non-ASCII backward-pointing address in the envelo= pe or
headers, making that decision is not straightforwar= d.  That
leads to a strong case that, if one wants b= road deployment of
SMTPUTF8, the place to start is with t= he MUAs (including the
Webmail systems) and associated PO= P and IMAP servers and
clients.  The "to various ex= tents" list in the first part of
Section 3 is not particu= larly helpful in that regard.

(7) Fina= lly, this is an internationalization (i18n) problem as
mu= ch as it is an email problem.  Terminology (and, where
characters or code points are referred to, their precise
identification) is very important because the alternative is
typically a good deal of user confusion about what you are
talking about and other impediments to making progress.  Say= ing
"English" were you mean "Basic Latin Script" or "ASCI= I" is not
helpful, especially given that 5321 local parts= can include any
ASCII character and that ASCII is not su= fficient to write
English.  Conversely, it appears t= hat there are a few places
where, correctly or incorrectl= y, you really do mean "English"
when you say that.  = Similarly, talking about one particular
encoding when yo= u mean "Unicode" is confusing and may be
misleading. = ; RFC 6365 may give you a start on some of the issues.
regards,
    john


  -------------
[1] I recommend the authors have a look at RFC 5137.

[2] Punycode is an encoding method, not a display = format.  See
RFC 5890, Section  2.3.4.

[3] http://unicode.org/reports/tr9/

_______________________________________________
IMA= mailing list
IMA@ietf.org
https://www.ietf.org/mailman/listinfo/ima


------=_Part_326692_104934480.1476458250628-- From nobody Fri Oct 14 08:19:52 2016 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C84AA129523 for ; Fri, 14 Oct 2016 08:19:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eiZYRZHKaBCx for ; Fri, 14 Oct 2016 08:19:46 -0700 (PDT) Received: from nm21.bullet.mail.ne1.yahoo.com (nm21.bullet.mail.ne1.yahoo.com [98.138.90.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69614129506 for ; Fri, 14 Oct 2016 08:19:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1476458385; bh=gHXggEzNVEXcL1CXHfuV0yr7ErYUa5BYLlWG+ZVaRLU=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=hTq5MxWYjvNqVHKJdRjxOytzIgHE4J3INDbuLVwbbk5pJxkYNtvqdvjyYnPGkqX3xmV8Ewr7F3nYRF96kbMHKofFVI1Ur1YVDCrvdC47+uRZFhKzNmI+nVUpb0yr98466+MhIudM1u/bQQ9tXld568pRezYbUvCDOoYEDVx9ZyzdLjPjSi4wsNECukRy6sApCzpe02PjzQg8fRbaHgS2PKwBe/sDGWWGiuYuA4KzWKZPy8BIrjXgie/UjvHgVq0WL1ZExcrHxoBRiO9PX3fm5wvgrhh1jO3rHOpSTyKG4fkU3QIvogZqvUXOiM9Kt8ftjVuMoMWssF7vGD9MTHVFJQ== Received: from [98.138.226.179] by nm21.bullet.mail.ne1.yahoo.com with NNFMP; 14 Oct 2016 15:19:45 -0000 Received: from [98.138.89.192] by tm14.bullet.mail.ne1.yahoo.com with NNFMP; 14 Oct 2016 15:19:45 -0000 Received: from [127.0.0.1] by omp1050.mail.ne1.yahoo.com with NNFMP; 14 Oct 2016 15:19:45 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 832869.41820.bm@omp1050.mail.ne1.yahoo.com X-YMail-OSG: TLY8PvMVM1mPLk0tehiGw6g58A.O7CKEXNGdkjMaTrTp3E0p7wg593sFr6NLna7 _Sh4lfPeaknRtRdWZTr5WRjZWoHXFJRTTn6eqzp9thxGqRD7hmQ5iJvtVob9mYXtd5D9v_YNehNR R_IRGekQSYnFhVEWz3HUnWPGt4SVkRd3yRPN9yZGhWNkWSZRM5QOrQ2pObJImmaf44bhU1_tkpLF topWi41dO4dsHuQ8XHrkDl_5JyUWwalrUXfVhti0BLyK7U49OikmKzNLZ.0jCb51vT5rdA5Q8AFL WjPKE.kKy1bbjO16TjFTK7IjduJO7r4A3Uejc1MyX2_BzwJk8CsD8Onc6yl09ClKxp.nTHM6NdiF gsfBuCTnJGndB8MnvvxYaL133Pq5Q0uxJTu_i0of9zuuthRW7Cm9v0nbdoWTPvMXNXZEii.SUTyN WjUtvHA0EA7WjiYtwiVodAobJhq3Ze1A_vRxTSs8wfVctvi6.7fAR.X6QYP.oCnHs8CEw9hWPaS. cB1XAuh6u1iNbhogei1YZB.K2fsQF8eEWbWa8mop5Odfmz78c4rbZui5WVarsTiU- Received: from jws200038.mail.ne1.yahoo.com by sendmailws140.mail.ne1.yahoo.com; Fri, 14 Oct 2016 15:19:45 +0000; 1476458385.294 Date: Fri, 14 Oct 2016 15:19:44 +0000 (UTC) From: To: Andrew Sullivan , "ima@ietf.org" Message-ID: <392618324.335159.1476458384653@mail.yahoo.com> In-Reply-To: <20161014150850.GA43040@mx2.yitter.info> References: <20161006055447.32573.qmail@pro-236-157.rediffmailpro.com> <9EC0EB65-9C58-43ED-9A80-1DA32C58E3E0@att.com> <1600128477.303347.1476456552432@mail.yahoo.com> <20161014150850.GA43040@mx2.yitter.info> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_335155_1668942523.1476458384651" Archived-At: Cc: Harish Chowdhary Subject: Re: [EAI] [IETF] Display of Email Addresses [was: Internationalized Email Internet Draft] X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: nalini.elkins@insidethestack.com List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 15:19:51 -0000 ------=_Part_335155_1668942523.1476458384651 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Andrew, =20 On Fri, Oct 14, 2016 at 02:49:12PM +0000, nalini.elkins@insidethestack.com = wrote: >> This is a very interesting problem. =C2=A0 We are hoping to do some kind= of spreadsheet or other visual where we can show what happens with a numbe= r of mail servers. >I think that effort has already been undertaken by the "Universal=C2=A0Acc= eptance Steering Group" over in ICANN. Will reach out to them & see if we can get the results of their efforts. = =C2=A0 Thanks for pointing that out. =C2=A0 I believe Harish has already ha= d a number of discussions with that group & knows the people there. Nalini =C2=A0 =20 ------=_Part_335155_1668942523.1476458384651 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Andrew,



=

On= Fri, Oct 14, 2016 at 02:49:12PM +0000, nalini.elkins@insideth= estack.com wrote:
>> This is a very interesting= problem.   We are hoping to do some kind of spreadsheet or other visu= al where we can show what happens with a number of mail servers.

>I think that effort has already been under= taken by the "Universal Acceptance Steering Group" over in ICANN.


Will reach out to them & see if we can get the res= ults of their efforts.   Thanks for pointing that out.   I believ= e Harish has already had a number of discussions with that group & know= s the people there.


Nalini

 


------=_Part_335155_1668942523.1476458384651-- From nobody Fri Oct 14 08:32:54 2016 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D568E129847 for ; Fri, 14 Oct 2016 08:32:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LRMUDBm5mEks for ; Fri, 14 Oct 2016 08:32:49 -0700 (PDT) Received: from nm10-vm5.bullet.mail.ne1.yahoo.com (nm10-vm5.bullet.mail.ne1.yahoo.com [98.138.91.232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AB5B1294FD for ; Fri, 14 Oct 2016 08:32:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1476459168; bh=+VnW1IqXt3xUXwQiA+kH0BhLSc950NUCEK+WsuR7ByA=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=t+Mi1+tAe5CPZxZU2rkzRoF+1nuwZsXATUSbtPQzQNS/Jo00rp+1vV+tdKcEC1+bUviMEM4/+wRjoevd0KHoYNq+ocrpCjUd1tEkiB3x56lcKo95ew5i5Ys5zznQuBZEBzirOfUt4G4adXY4VtK7T2GKRYNl048NerbvSfPzLXqZatd7DZ5mte3KxGoifQf4bNlnI7wRhYub5IZofqKUIDvNjk92nBALECeekOPMe7htyZrHszeiyQ0hxZH2W1PtUtTKIKw8ObVPg45dkdNHChC1m+IQG8jGIsUmwUbKlny5xz4okl+Aq4SNmn9mq5ZZv9wdqOw6g5sPc45KTcx3SQ== Received: from [98.138.226.180] by nm10.bullet.mail.ne1.yahoo.com with NNFMP; 14 Oct 2016 15:32:48 -0000 Received: from [98.138.89.233] by tm15.bullet.mail.ne1.yahoo.com with NNFMP; 14 Oct 2016 15:32:48 -0000 Received: from [127.0.0.1] by omp1048.mail.ne1.yahoo.com with NNFMP; 14 Oct 2016 15:32:48 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 547580.83931.bm@omp1048.mail.ne1.yahoo.com X-YMail-OSG: gMezvH0VM1nYizIbp0iqVIJgD4U0kbMmQel2G.wj4sWbZiZNSZrw5XYJkoszzl1 6PtiJ_wehFFpJCAMS5MZkXveXN8xNBDWHnz9EyV1mc5HDa3O_7FwOhz3s3IRVPA8mYdVmrzq.ZlL S8KLW07OSFRZeV2DLAXjaY06PsL26A2bELsDrQoC_FUzt0IAZk2lQZ.Dimd4MX3MdYZxKnnXwB9m 4X6lNoZ1qZZVQ8XMuS_tyqHw9lKITUZL5xgxM3w3i8QR8cs.U3BZ..HfruviPfibo3wowrJhN1A5 d9AQh5zRxREobhQMI2.jY.m3vZ5W09tkNgsbV8mwv5FiyknEvHutezrz62stXeYlTceJ7BRaDjWh yfajsYA95b8x0RvD7HY2_P5oyNQdrTdB.PLJCzAIIHz_fMPezSNUvpzDI8e._KOIt2OzcqR3kS1B ZwaGkcqzHvC0oIY7OYcgqw.HADHpiNBzLHkX9bhKl73p4B9g0_wkiMSpw6UQk.KyzhxZ7xUjZycs 9AxbIlf6nbJWALyt_u_9H7xl3qGjXRSJ2sA1O7Y4f9NlwqRImq2Q- Received: from jws200162.mail.ne1.yahoo.com by sendmailws121.mail.ne1.yahoo.com; Fri, 14 Oct 2016 15:32:47 +0000; 1476459167.988 Date: Fri, 14 Oct 2016 15:31:02 +0000 (UTC) From: To: John C Klensin , "HANSEN, TONY L" , "ima@ietf.org" Message-ID: <856212672.339192.1476459062109@mail.yahoo.com> In-Reply-To: References: <20161006055447.32573.qmail@pro-236-157.rediffmailpro.com> <9EC0EB65-9C58-43ED-9A80-1DA32C58E3E0@att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Harish Chowdhary Subject: [EAI] [IETF] Migration / Backward Compatibility [was: Internationalized Email Internet Draft] X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: nalini.elkins@insidethestack.com List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 15:32:54 -0000 John / Tony, >(6) There is a necessary difficulty with SMTPUTF8, which is that one canno= t transmit a message with non-ASCII characters in addresses or headers to a= system that does not support them. >Final delivery systems should probably not accept messages unless they hav= e reason to predict that the mail store will handle them _and_ that the use= r associated with the target >mailbox will be able to retrieve them. Since a user with an all-ASCII mai= lbox name might still receive a message with, e.g., a non-ASCII backward-po= inting address in the envelope or >headers, making that decision is not straightforward. That leads to a str= ong case that, if one wants broad deployment ofSMTPUTF8, the place to start= is with the MUAs (including the >Webmail systems) and associated POP and IMAP servers and clients. The "to= various extents" list in the first part of Section 3 is not particularly h= elpful in that regard. This is a huge problem. Maybe the biggest problem of all. It is actually= shades of the IPv6 / IPv4 problem. I think we need to have a discussion = on migration strategies. Remember v4 - v6 tunneling? Hope we do not end up there! We can certain= ly talk more about some of the migration issues here. The reason for the "various extents" of support is an obfuscation because I= have not reverse engineered the servers / clients listed. (Nor do I plan = to!) But, let me just say this - without playing some "games" -- that is not act= ually supporting the RFCs on how to transmit email, I have a feeling that s= ome of these servers / clients would not work. But, I do not want to say m= ore without more thorough testing. And, maybe not even then.=20 Thanks, Nalini Elkins Inside Products, Inc. www.insidethestack.com (831) 659-8360 ________________________________ From: John C Klensin To: "HANSEN, TONY L" ; ima@ietf.org=20 Sent: Sunday, October 9, 2016 7:57 PM Subject: Re: [EAI] [IETF] Internationalized Email Internet Draft --On Thursday, October 06, 2016 4:39 PM +0000 "HANSEN, TONY L" wrote: > I think getting deployment feedback from EAI is important, and > this draft is an excellent start. >=20 > I'm not convinced that section 1.2 describes a real problem. > People do this all the time today with various combinations of > languages. Why is the combination of Russian and Chinese any > different? If you think it is, then please expand on the > aspect that does make it more difficult. >=20 > I forwarded a number of nits to the authors. Hi. I was going to hold off until some later and more mature version of this draft, but since Tony has commented, while I believe the issues with EAI deployment are important, I see several problems with this draft, some of which were actually discussed in the WG but appear to be ignored here. Perhaps more important, it is seriously incomplete relative to issues that have been discussed at great length in the EAI WG, at the APEC meeting on internationalized email in Beijing in October 2014, the May 2015 workshop in Thailand, and elsewhere. I strongly suggest that, if there is going to be a discussion in Seoul, this document is in need of a great deal of work first. Some of those issues are: (1) The so-called EAI standards, as listed in the Introduction, are about email envelope and header information presented directly (e.g., in UTF-8) as non-ASCII characters. A good deal of the document appears to address mail content information such as textual message bodies, in other scripts. With the possible exception of language selection when a message is sent with the same basic text in several languages (multipart/alternative was designed with that case in mind but have been used in other ways), we thought we solved that content problem with MIME in 1992. If MIME is inadequate, the authors or others should produce a document explaining the issues and not confuse them with EAI / SMTPUTF8. If it is adequate, then, like Tony although perhaps for different reasons, I don't see what Section 1.2 is doing here, what the relevance of Section 3.2 is, and several other statements should be examined carefully to be sure they are talking about addresses and/or headers and not content. (2) Within an address, there is, as the I-D points out and consistent with RFC 5321, a local part and a domain part. RFCs 6530 and 6531 make it quite clear (at least we thought they did) that they are handled differently. For the domain part, the rules are laid out in the IDNA2008 specs (RFC 5890ff). Issues about look-alike characters have been extensively discussed and written about (even though some of us have questioned the quality of some of that work). It does not seem useful to me to revisit those issues here, especially without reference to the prior work and discussions or if some of the discussion here is wrong or contains obvious omissions. As an example from the first paragraph of Section 6.1, Latin "c" (U+0063) and Cyrillic "c" (U+0441) are typically written with identical graphemes, but are not on the list. More important, while the "paypal" example with U+0430 substituted for "a" (U+0061) has been used repeatedly, including in a careful study in an article that is not cited in this draft, it is possible to write "=D1=80=D0=B0=D1=83=D1=80= =D0=B01" with the first five characters in Cyrillic and the last one a digit (which is script independent) (\u'0440'\u'0430'\u'0443'\u'0440'\u'040'\u'0031' [1]), therefore not even violating conventions prohibiting mixed-script labels. There is, of course, no ambiguity in the A-label form, although the authors quite properly point out that it is not user-friendly. By contrast, Section 1.1 talks about display of email addresses, including the local part ("in Punycode" [2]). While a mail delivery server is free to create whatever aliases for a mailbox local part it likes, including "xn-t2bmh3a" or "123456", "george" or "example", in general converting a local part using the Punycode algorithm and displaying the result is prohibited by the EAI standards (and, incidentally, RFC5321). More important, it will often lose information and is potentially very dangerous. (3) Arabic should not be confused with a strictly right-to-left writing system. I am not aware of any such systems in wide use for contemporary languages today. The problem is that numerals, whether written in European digits, Arabic or Arabic-Indic digits, Chinese (Han) digits, or many others, have been written left to right since that type of positional notation was invented and became widely used. As a result, the scripts are referred to (in Unicode-speak) as "bidirectional" or "bidi" [3]. Their implications for domain names and IDNA are the subject of RFC 5893. (4) Multiple addresses for one user (and Section 4). Keeping in mind that many people maintain a number of identities, and even multiple email addresses, for different purposes, I don't understand what point you are trying to make with this section. Many of us believe that users who have mailboxes whose names involve non-ASCII local parts and who engage in communications outside their primary language group will find it necessary to maintain either separate all-ASCII mailboxes or all-ASCII aliases to their primary mailboxes and to do so for a very long time. That issue has been extensively analyzed and discussed but this document avoids that work, which is both a problem and an opportunity. (5) Section 2.1 asserts that email servers), implying all of them, store data (messages?) in relational databases. That is simply false. Some do; others don't. Even for those that do, there may be a difference between Unicode-capable data storage and Unicode-capable keys or indexes. There is also absolutely no requirement that any such system store Unicode strings encoded in UTF-8; many do not. =20 (6) There is a necessary difficulty with SMTPUTF8, which is that one cannot transmit a message with non-ASCII characters in addresses or headers to a system that does not support them. Final delivery systems should probably not accept messages unless they have reason to predict that the mail store will handle them _and_ that the user associated with the target mailbox will be able to retrieve them. Since a user with an all-ASCII mailbox name might still receive a message with, e.g., a non-ASCII backward-pointing address in the envelope or headers, making that decision is not straightforward. That leads to a strong case that, if one wants broad deployment of SMTPUTF8, the place to start is with the MUAs (including the Webmail systems) and associated POP and IMAP servers and clients. The "to various extents" list in the first part of Section 3 is not particularly helpful in that regard. (7) Finally, this is an internationalization (i18n) problem as much as it is an email problem. Terminology (and, where characters or code points are referred to, their precise identification) is very important because the alternative is typically a good deal of user confusion about what you are talking about and other impediments to making progress. Saying "English" were you mean "Basic Latin Script" or "ASCII" is not helpful, especially given that 5321 local parts can include any ASCII character and that ASCII is not sufficient to write English. Conversely, it appears that there are a few places where, correctly or incorrectly, you really do mean "English" when you say that. Similarly, talking about one particular encoding when you mean "Unicode" is confusing and may be misleading. RFC 6365 may give you a start on some of the issues. regards, john ------------- [1] I recommend the authors have a look at RFC 5137. [2] Punycode is an encoding method, not a display format. See RFC 5890, Section 2.3.4.=20 [3] http://unicode.org/reports/tr9/ _______________________________________________ IMA mailing list IMA@ietf.org https://www.ietf.org/mailman/listinfo/ima From nobody Fri Oct 14 08:42:01 2016 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79FE1129536 for ; Fri, 14 Oct 2016 08:42:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L145v-TmF4Jl for ; Fri, 14 Oct 2016 08:41:54 -0700 (PDT) Received: from nm14-vm3.bullet.mail.ne1.yahoo.com (nm14-vm3.bullet.mail.ne1.yahoo.com [98.138.91.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 908BB1294A1 for ; Fri, 14 Oct 2016 08:41:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1476459713; bh=poXQ+IaLji9nXDHnUZj1lzWGmdFKzc52C8kwnyvpn3I=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=TbTKnZCsY2U/E2qrLLogSMA8GXrTOhh/OmY1KAURgJXvtXm/EM/uCadJ/WRvoobcGicrPY3cPk/uXptJzhXq8q2IU9olDK8z+lXJjWvCCvDwPkoD2lNGEQG6HAUxbcBeANrd3pozYfynoOUG+dQspt3uz4enyVwFjmGhiv9hO2vIUAhJP/1nalSaYAWyORNxX+5+OVWrmvMfqQ8x72OT1qvoCm91SsR+jQViStGwjEFxNHbT02ThWknueb9tYgMzaAgl6pIEt8jhfwnjYNfDjNFXWT+vrC7BiYWQAYj7Y6Six8PqxHTrZ8iF+z5u3h2Vn+oiLhymqyHZILN5eZd+tw== Received: from [98.138.100.115] by nm14.bullet.mail.ne1.yahoo.com with NNFMP; 14 Oct 2016 15:41:53 -0000 Received: from [98.138.86.156] by tm106.bullet.mail.ne1.yahoo.com with NNFMP; 14 Oct 2016 15:41:53 -0000 Received: from [127.0.0.1] by omp1014.mail.ne1.yahoo.com with NNFMP; 14 Oct 2016 15:41:53 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 671575.67986.bm@omp1014.mail.ne1.yahoo.com X-YMail-OSG: XKkGlhMVM1kePs9xk6qXmNx_UaYFltJNryQHYuEAyP6Q7VGD2pH5Clp3A3CdeDg l593Cxb3tbY.kmy9XkRzozZKl13NJsXnA4Mhp0yP9x3KPRibAmCjxC3_zMXEbn0MSB7v9K_cSlEt vL95urREv5zu7MQGrPoURPgtVe65IILJUQOJjVrQv5hS5XtrZcZqnBc4DCp2d_q_G5P9k11KcQxY XN6q9m2hETwLZNiyTZ1ERpl8mx8dEHJ7f6TXObamov6HcDPYhdlnRi0_H6pKBf1l9js5F99SA9wd zETYzBROMnEaOdwRGdGVn8loiC0JCxXZimtFpCPX7vFsZya3TTwxDWXInmmguIqZS7VIChDhb2cJ 7DzDOfVuFR4tnl3qCuul2NOweT3Ept6koY6d1wQKFOqfmVLjLUXQeLW.9CQCaWxByxmEsvx6rZlq CUWPbosaEahHHX.y4W6voUol5m4VEK4fxgLojTXXbJxRfVowllw96B28PRwdHSfDnrLxKaEC5pmA XDrpu41jQcL_MOY9n11h0VEWruU3TY1W.o93xNfrslsLibqSobws- Received: from jws200060.mail.ne1.yahoo.com by sendmailws169.mail.ne1.yahoo.com; Fri, 14 Oct 2016 15:41:53 +0000; 1476459713.289 Date: Fri, 14 Oct 2016 15:41:45 +0000 (UTC) From: To: John C Klensin , "HANSEN, TONY L" , "ima@ietf.org" Message-ID: <1044067629.355320.1476459705455@mail.yahoo.com> In-Reply-To: References: <20161006055447.32573.qmail@pro-236-157.rediffmailpro.com> <9EC0EB65-9C58-43ED-9A80-1DA32C58E3E0@att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Harish Chowdhary Subject: [EAI] [IETF] Terminology [was: Internationalized Email Internet Draft] X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: nalini.elkins@insidethestack.com List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 15:42:00 -0000 John / Tony, >(7) Finally, this is an internationalization (i18n) problem as much as it = is an email problem. Terminology (and, where characters or code points are= referred to, their precise=20 >identification) is very important because the alternative is typically a g= ood deal of user confusion about what you are talking about and other imped= iments to making progress. Saying=20 >"English" were you mean "Basic Latin Script" or "ASCII" is not helpful, es= pecially given that 5321 local parts can include any ASCII character and th= at ASCII is not sufficient to write=20 >English. Conversely, it appears that there are a few places where, correc= tly or incorrectly, you really do mean "English" when you say that. Simila= rly, talking about one particular=20 >encoding when you mean "Unicode" is confusing and may be misleading. RFC = 6365 may give you a start on some of the issues. =20 Thanks for pointing that out. I will go through the draft and fix. Thanks, Nalini Elkins Inside Products, Inc. www.insidethestack.com (831) 659-8360 ----- Original Message ----- From: John C Klensin To: "HANSEN, TONY L" ; ima@ietf.org Sent: Sunday, October 9, 2016 7:57 PM Subject: Re: [EAI] [IETF] Internationalized Email Internet Draft --On Thursday, October 06, 2016 4:39 PM +0000 "HANSEN, TONY L" wrote: > I think getting deployment feedback from EAI is important, and > this draft is an excellent start. >=20 > I'm not convinced that section 1.2 describes a real problem. > People do this all the time today with various combinations of > languages. Why is the combination of Russian and Chinese any > different? If you think it is, then please expand on the > aspect that does make it more difficult. >=20 > I forwarded a number of nits to the authors. Hi. I was going to hold off until some later and more mature version of this draft, but since Tony has commented, while I believe the issues with EAI deployment are important, I see several problems with this draft, some of which were actually discussed in the WG but appear to be ignored here. Perhaps more important, it is seriously incomplete relative to issues that have been discussed at great length in the EAI WG, at the APEC meeting on internationalized email in Beijing in October 2014, the May 2015 workshop in Thailand, and elsewhere. I strongly suggest that, if there is going to be a discussion in Seoul, this document is in need of a great deal of work first. Some of those issues are: (1) The so-called EAI standards, as listed in the Introduction, are about email envelope and header information presented directly (e.g., in UTF-8) as non-ASCII characters. A good deal of the document appears to address mail content information such as textual message bodies, in other scripts. With the possible exception of language selection when a message is sent with the same basic text in several languages (multipart/alternative was designed with that case in mind but have been used in other ways), we thought we solved that content problem with MIME in 1992. If MIME is inadequate, the authors or others should produce a document explaining the issues and not confuse them with EAI / SMTPUTF8. If it is adequate, then, like Tony although perhaps for different reasons, I don't see what Section 1.2 is doing here, what the relevance of Section 3.2 is, and several other statements should be examined carefully to be sure they are talking about addresses and/or headers and not content. (2) Within an address, there is, as the I-D points out and consistent with RFC 5321, a local part and a domain part. RFCs 6530 and 6531 make it quite clear (at least we thought they did) that they are handled differently. For the domain part, the rules are laid out in the IDNA2008 specs (RFC 5890ff). Issues about look-alike characters have been extensively discussed and written about (even though some of us have questioned the quality of some of that work). It does not seem useful to me to revisit those issues here, especially without reference to the prior work and discussions or if some of the discussion here is wrong or contains obvious omissions. As an example from the first paragraph of Section 6.1, Latin "c" (U+0063) and Cyrillic "c" (U+0441) are typically written with identical graphemes, but are not on the list. More important, while the "paypal" example with U+0430 substituted for "a" (U+0061) has been used repeatedly, including in a careful study in an article that is not cited in this draft, it is possible to write "=D1=80=D0=B0=D1=83=D1=80= =D0=B01" with the first five characters in Cyrillic and the last one a digit (which is script independent) (\u'0440'\u'0430'\u'0443'\u'0440'\u'040'\u'0031' [1]), therefore not even violating conventions prohibiting mixed-script labels. There is, of course, no ambiguity in the A-label form, although the authors quite properly point out that it is not user-friendly. By contrast, Section 1.1 talks about display of email addresses, including the local part ("in Punycode" [2]). While a mail delivery server is free to create whatever aliases for a mailbox local part it likes, including "xn-t2bmh3a" or "123456", "george" or "example", in general converting a local part using the Punycode algorithm and displaying the result is prohibited by the EAI standards (and, incidentally, RFC5321). More important, it will often lose information and is potentially very dangerous. (3) Arabic should not be confused with a strictly right-to-left writing system. I am not aware of any such systems in wide use for contemporary languages today. The problem is that numerals, whether written in European digits, Arabic or Arabic-Indic digits, Chinese (Han) digits, or many others, have been written left to right since that type of positional notation was invented and became widely used. As a result, the scripts are referred to (in Unicode-speak) as "bidirectional" or "bidi" [3]. Their implications for domain names and IDNA are the subject of RFC 5893. (4) Multiple addresses for one user (and Section 4). Keeping in mind that many people maintain a number of identities, and even multiple email addresses, for different purposes, I don't understand what point you are trying to make with this section. Many of us believe that users who have mailboxes whose names involve non-ASCII local parts and who engage in communications outside their primary language group will find it necessary to maintain either separate all-ASCII mailboxes or all-ASCII aliases to their primary mailboxes and to do so for a very long time. That issue has been extensively analyzed and discussed but this document avoids that work, which is both a problem and an opportunity. (5) Section 2.1 asserts that email servers), implying all of them, store data (messages?) in relational databases. That is simply false. Some do; others don't. Even for those that do, there may be a difference between Unicode-capable data storage and Unicode-capable keys or indexes. There is also absolutely no requirement that any such system store Unicode strings encoded in UTF-8; many do not. =20 (6) There is a necessary difficulty with SMTPUTF8, which is that one cannot transmit a message with non-ASCII characters in addresses or headers to a system that does not support them. Final delivery systems should probably not accept messages unless they have reason to predict that the mail store will handle them _and_ that the user associated with the target mailbox will be able to retrieve them. Since a user with an all-ASCII mailbox name might still receive a message with, e.g., a non-ASCII backward-pointing address in the envelope or headers, making that decision is not straightforward. That leads to a strong case that, if one wants broad deployment of SMTPUTF8, the place to start is with the MUAs (including the Webmail systems) and associated POP and IMAP servers and clients. The "to various extents" list in the first part of Section 3 is not particularly helpful in that regard. (7) Finally, this is an internationalization (i18n) problem as much as it is an email problem. Terminology (and, where characters or code points are referred to, their precise identification) is very important because the alternative is typically a good deal of user confusion about what you are talking about and other impediments to making progress. Saying "English" were you mean "Basic Latin Script" or "ASCII" is not helpful, especially given that 5321 local parts can include any ASCII character and that ASCII is not sufficient to write English. Conversely, it appears that there are a few places where, correctly or incorrectly, you really do mean "English" when you say that. Similarly, talking about one particular encoding when you mean "Unicode" is confusing and may be misleading. RFC 6365 may give you a start on some of the issues. regards, john ------------- [1] I recommend the authors have a look at RFC 5137. [2] Punycode is an encoding method, not a display format. See RFC 5890, Section 2.3.4.=20 [3] http://unicode.org/reports/tr9/ _______________________________________________ IMA mailing list IMA@ietf.org https://www.ietf.org/mailman/listinfo/ima From nobody Fri Oct 14 08:45:36 2016 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEAD3129845 for ; Fri, 14 Oct 2016 08:45:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.896 X-Spam-Level: X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CFvd1d7M3zHR for ; Fri, 14 Oct 2016 08:45:30 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C91E512944D for ; Fri, 14 Oct 2016 08:45:29 -0700 (PDT) Received: from [198.252.137.10] (helo=JcK-HP8200) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1bv4fj-000As5-EL; Fri, 14 Oct 2016 11:45:23 -0400 Date: Fri, 14 Oct 2016 11:45:18 -0400 From: John C Klensin To: nalini.elkins@insidethestack.com, "HANSEN, TONY L" , ima@ietf.org Message-ID: <8B119C286A3CFDE08C598251@JcK-HP8200> In-Reply-To: <489025644.216489.1476451836537@mail.yahoo.com> References: <20161006055447.32573.qmail@pro-236-157.rediffmailpro.com> <9EC0EB65-9C58-43ED-9A80-1DA32C58E3E0@att.com> <489025644.216489.1476451836537@mail.yahoo.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: klensin@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: Harish Chowdhary , Peter Saint-Andre Subject: [EAI] General issues and strategy (was: Re: Content Issues [ was: Internationalized Email Internet Draft]) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 15:45:35 -0000 Nalini, Given your decision to go for separate threads, which I think is a good one, some general comments: --On Friday, October 14, 2016 13:30 +0000 nalini.elkins@insidethestack.com wrote: > John / Tony, > I am going to split your comments into separate threads so > that I can keep track of each. =C2=A0=20 >... > Yes. =C2=A0I see your point. =C2=A0 Let me say first the basic = thing > that we are trying to do is to discuss the holistic user > experience of internationalized emails from an operational > point of view. =C2=A0 In so doing, the co-mingling happened. = =C2=A0We > could do a second draft for content issues or change the > abstract of this one to better state what our real goal is. > Secondly, as you guys know well, there are lots of other > issues with IDN, browser support, etc. =C2=A0 What we were > actually hoping is that we could have a forum (perhaps like > DNSOps or v6Ops) where we could come together to define and > discuss such problems, move towards best practices (or work > arounds! Not that I like that, but it happens.) =C2=A0 Because = we > have not even started on problems that we see such as search > algorithm ranking of IDNs and so on. =C2=A0 We were hoping = that > others would step up to author such other drafts. A few very general comments about context. This might anticipate some future note from you, so I hope I can get it off quickly... (1) I trust you are aware of the ICANN=3D-sponsored "Universal Acceptance" effort, which is covering some of this same ground. Personally, I believe they are seriously out in the weeds, doing a good deal of work on assumptions about the DNS and the EAI work that are just not valid for a number of technical reasons, but it would be unfortunate to waste whatever cycles are associated with duplicative efforts. As far as I know, Don Holland is still lead; I think he is on the EAI list but am not sure. (2) I trust you are also aware that there is an IAB I18N program. It has been, again IMO, fairly unhealthy in the last couple of years, largely because the available cycles of the most active and expert people have disappeared into the IANA Transition activity. If you want a forum or workshop, they might be a good place to start. Ted Hardie is lead; I have no idea whether he is on the EAI list. (3) Despite the obvious interest and importance of this issue, I have observed very little actual energy in the IETF for dealing with it or i18n issues more generally. By the time the EAI WG got its documents out, there was little interest in specific work beyond "we just want this to work". By the time the PRECIS WG got its RFCs out, there was little general interest in careful review of documents (resulting in a need to start work on revisions almost immediately thereafter). AFAICT, the strongest and most general sentiment in the WG was "just tell me what to do so I don't need to understand or think about this". That is understandable, but not a good foundation for getting work done. The community has been completely unable to engage with the "non-decomposing character" issue that has paralyzed some important IDNA applications for a couple of years now (IMO, the LUCID BOF, supposedly addressed to that issue, did a good job of illustrating the more fundamental problems with IETF engagement, including a lengthy discussion of just how to spell Z=C3=BCrich in English (or, for that matter, in various versions = of German). =20 (4) Even among those who were active in the EAI work, there has been, AFAICT, silence so far except from Tony and myself. I know that some are off chasing general equivalence of DNS names. I believe that effort shows a fundamental lack of understanding of the properties of the relevant data structures but it seems to be getting agenda time in Seoul (see "DNSBUNDLED" on Jari's "New Work in Seoul" BOF list). (5) You should also be sure you understand that many of the issues with non-ASCII identifiers, especially identifiers=20 (5) If you want rapid deployment of fully-internationalized email messages, it is important that you understand that there were alternate hypotheses for how to get both the IDN and that work done. For IDNs, we could have changed the DNS and server matching algorithms (which might have permitted approximate matching and made a number of issues with comparison and normalization much easier) or we could have adopted an "above DNS" model which would have also helped with the matching and search issues. However, there was a great deal of pressure, some of it emotional and paralleling the comments about "English" in your draft, for "fast" and "in the DNS", and that got us the mappings, restrictions, and trick encoding of IDNA. Every bit of new evidence or pressure for synonymous labels and matching that is predictable given local language culture is an argument that we got it wrong and should have gone for one of the other approaches, probably a member of the "Above DNS" family. For EAI, there was a similar choice. We could have stuck with all-ASCII address local parts and focused on better use of encoded names (e.g., by making it clear that not copying a name phrase into a reply or to or from an address book was a very bad practice, encouraging address book lookups by the name phrase or equivalent as well as the address, etc., thereby saving a good many transition and interoperability problems. I note that was the solution adopted by the ITU, an organization with far more representation and influence from countries and people who speak English as a second language if at all, for a broad range of I19n issues. Instead, there was a strong commitment in the WG and those who pushed for it to have all-non-ASCII mailbox addresses and to phase out the encoded word approach. At least a significant fraction of the WG understood the likely (or certain) costs of that decision including slow deployment and interoperability issues that would likely limit EAI use to "within community" communications. If, at any point, you want to argue for discarding SMTPUTF8 and returning to an encoded word model, there are less difficult (but also less culturally and aesthetically attractive) ways to move forward. best, john (BTW, as a further illustration of the "too few people with spare cycles" problem, I'm writing this note rather than working on the current round of PRECIS revision drafts (and they are, in turn, holding up work in URNBIS) and am copying Peter, who I don't think is on the EAI list either, so he knows what is happening.) From nobody Fri Oct 14 08:57:37 2016 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B72261294A1 for ; Fri, 14 Oct 2016 08:57:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gVcBxvd5YwI8 for ; Fri, 14 Oct 2016 08:57:32 -0700 (PDT) Received: from nm26.bullet.mail.ne1.yahoo.com (nm26.bullet.mail.ne1.yahoo.com [98.138.90.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FFE71293FF for ; Fri, 14 Oct 2016 08:57:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1476460651; bh=ePWJMiwwy/2jdNjpN52yfyxQSJu7HokH27ADIQWrqwA=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=gb26k+ZqOtVuP/RmeP2QGz5jz6H48bIkk8kFQr8HbrZa0jr557dply9EjsgfX6ylYnWRRzvsQCfdMaTGHVt1zvXrlQCUnRfOCJyf9HppR8JLxhMKqvQv1T7Djlh3EF6psYkNeC2L+FSlV/HlmLRrJw36bh2ORfPpmBXQDMPjdy/MzEhczTGue1YQCSONrrKZl7gPJ6xuwZ3raJIysNTZ+coVZZwls6iBr4aOIpP3ED3apnz1QIo2hsz7/gx3ow4WeybDs4E2JAnMtUSN9QGOmxRHs2Rv00A5+SAWUvLK8Vo3dymvlSvcElLR5ElEgo8b/iXwYljxWATV7XqcEuGU7w== Received: from [98.138.100.118] by nm26.bullet.mail.ne1.yahoo.com with NNFMP; 14 Oct 2016 15:57:31 -0000 Received: from [98.138.89.170] by tm109.bullet.mail.ne1.yahoo.com with NNFMP; 14 Oct 2016 15:57:31 -0000 Received: from [127.0.0.1] by omp1026.mail.ne1.yahoo.com with NNFMP; 14 Oct 2016 15:57:31 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 577875.51845.bm@omp1026.mail.ne1.yahoo.com X-YMail-OSG: Oq0p6SoVM1kzFF9QeQRSKJnPU3Q1gs3gExUVO6_Ne55wDiTfarYHe6EEGH9gGkc l4GbC2lnSwC9RbnwfRX_4zLvg897D.WRekUGVrMyLWFDHth4I9utsDkQmuERUZNZ4ELGdnsttHil udk.eeMoAhdctvh8FMyid3biaMYwxKKWJmDX8W8PpKEPoYWBZKlsfV.07PGixnG8Umbe4z2REFaQ GZWE6zSwzeFhpm9Ic8T8zBehhIlfJv1aPAmb2d9Wbaa0NZc2xNQ23wDTUTAmzIpCsRk5HFczfwTl sn0JDu.vKRdZVdUeX9VJFQk8g_fa6mQzvG_faxX0fbw26UiNjghdttHWwqZmNdaoI9yVOKCKVPAL Ft4wJXyKhkawTjgp.VLF81eVgAnGSmN8xZHv2HeD0s39SKduxPtsb3ueiaVJkmR0X6zgn9jKgrEl o4oL2emHH23.XiOXuG7DFWPgjlI2rljGothxKAXcXlIMisfHsTxdV8iVN7V0_qsgMg7R3KZoZgKL MNSJNOEZSC9muabCVtHrswM9rARQBYd5Gz3Ye Received: from jws200135.mail.ne1.yahoo.com by sendmailws120.mail.ne1.yahoo.com; Fri, 14 Oct 2016 15:57:31 +0000; 1476460651.108 Date: Fri, 14 Oct 2016 15:56:55 +0000 (UTC) From: To: "HANSEN, TONY L" , "ima@ietf.org" Message-ID: <1494946295.365614.1476460615866@mail.yahoo.com> In-Reply-To: <9EC0EB65-9C58-43ED-9A80-1DA32C58E3E0@att.com> References: <20161006055447.32573.qmail@pro-236-157.rediffmailpro.com> <9EC0EB65-9C58-43ED-9A80-1DA32C58E3E0@att.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_365613_43566037.1476460615861" Archived-At: Subject: Re: [EAI] [IETF] Internationalized Email Internet Draft X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: nalini.elkins@insidethestack.com List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 15:57:37 -0000 ------=_Part_365613_43566037.1476460615861 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Tony, >I=E2=80=99m not convinced that section 1.2 describes a real problem. Peopl= e do this all the time today with various combinations of languages. Why is= the combination of Russian and Chinese any >different? If you think it is,= then please expand on the aspect that does make it more difficult. I think what we were thinking of is the actual difficulties involved in typ= ing or user interface on a desktop. =C2=A0For example, if you are speaking = in a particular language and don't have the associated keyboard for it, the= n you might have to bring up a virtual keyboard to type in a particular lan= guage. =C2=A0Then, you might have to set the language preference on your de= sktop. =C2=A0 If you use a second language, then it becomes more complicated. =C2=A0 So, = you have two virtual keyboards + an actual physical keyboard? =C2=A0Hmm. I guess I am also assuming that in real life, you would actually be speakin= g both languages and not trying to do something like a "google translate" t= o read the message from the second language. =C2=A0Let me think how to reph= rase this section. Also, I think we have to distinguish between mobile and desktop. =C2=A0 On = my cell phone, I easily go back and forth from, for example, my english key= board, and emoji or bitmoji keyboard. =C2=A0So, I think that it would be ea= sy enough to go from english to hindi to french and then back to insert som= e emoji's. =C2=A0 Just thinking out loud about how this would actually work= . =C2=A0(This is making me think that maybe I text too much! =C2=A0Why am I= doing all this back and forth even now?=C2=A0) =C2=A0 >I forwarded a number of nits to the authors. Thanks! Nalini=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 Tony Hansen =C2=A0 From: IMA on behalf of Harish Chowdhary Reply-To: "harish@nixi.in" Date: Thursday, October 6, 2016 at 1:54 AM To: "ima@ietf.org" Subject: [EAI] [IETF] Internationalized Email Internet Draft =C2=A0 Dear All, Greetings! We have just posted an INTERNET DRAFT=C2=A0 on deployment Issues of Interna= tional Emails on IETF. https://datatracker.ietf.org/doc/draft-elkchow-iea-deploy/?include_text=3D1 Here is a brief description of what we want to discuss during IETF 97 (Seou= l,South Korea) International Email Addresses (IEA) are far from the global reality. The cu= rrent de-facto language of the Internet is English.=C2=A0 Even today, many = of the users of the Internet do not speak English as their primary language= .=C2=A0 The next billion users of the Internet are likely to be even less familiar with English. IEA is probably the firs= t application needed in a truly internationalized Internet.=C2=A0 The Email= Address Internationalization (EAI) Working Group defined the RFCs to suppo= rt internationalized email.=C2=A0 The time may now finally have come to develop best practices and to discuss the dep= loyment challenges for IEA. Your feedback and suggestions are most welcome to make above cited draft in= clusive of all the matters related to "Deployment of International Emails. We may further extend it to take up all the UA related issues. Hoping for your support. Thanks, Harish Chowdhary ---------------------------------------------------------------------------= ---------------------------------------------------- [NIXI is on Social-Media too. Kindly follow us at: Facebook: https://www.facebook.com/nixiindia & Twitter: @inregistry ] This e-mail is for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies and the original message. Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this email is strictly prohibited and appropriate legal action will be taken. ---------------------------------------------------------------------------= ---------------------- _______________________________________________ IMA mailing list IMA@ietf.org https://www.ietf.org/mailman/listinfo/ima ------=_Part_365613_43566037.1476460615861 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Tony,


>I=E2=80=99= m not convinced that section 1.2 describes a real problem. People do this a= ll the time today with various combinations of languages. Why is the combin= ation of Russian and Chinese any >different? If you think it is, then pl= ease expand on the aspect that does make it more difficult.


I think what we were thinking of is the actual difficulties invol= ved in typing or user interface on a desktop.  For example, if you are= speaking in a particular language and don't have the associated keyboard f= or it, then you might have to bring up a virtual keyboard to type in a part= icular language.  Then, you might have to set the language preference = on your desktop.  

If you use = a second language, then it becomes more complicated.   So, you have tw= o virtual keyboards + an actual physical keyboard?  Hmm.

I guess I am also assuming that in real life, y= ou would actually be speaking both languages and not trying to do something like a "google translat= e" to read the message from the second language.  Let me think how to = rephrase this section.

Also,= I think we have to distinguish between mobile and desktop.   On my ce= ll phone, I easily go back and forth from, for example, my english keyboard= , and emoji or bitmoji keyboard.  So, I think that it would be easy en= ough to go from english to hindi to french and then back to insert some emo= ji's.   Just thinking out loud about how this would actually work. &nb= sp;(This is making me think that maybe I text too much!  Why am I doin= g all this back and forth even now? 3D"*;))

 
>I forwarded a number= of nits to the authors.

Thanks!

Nalini
 
  &nb= sp;            = Tony Hansen
 
From: IMA <ima-bounces@ietf.org> on behalf= of Harish Chowdhary <harish@nixi.in>
Reply-To: "harish@nixi.in" &= lt;harish@nixi.in>
Date: Thursday, October 6, 2016 at 1:54 AM
To: = "ima@ietf.org" <ima@ietf.org>
Subject: [EAI] [IETF] Internationali= zed Email Internet Draft
 
Dear All,
Greetings!

We hav= e just posted an INTERNET DRAFT  on deployment Issues of International= Emails on IETF.

https://datatracker.ietf.org/doc/draft-elkchow-iea-= deploy/?include_text=3D1

Here is a brief description of what we want= to discuss during IETF 97 (Seoul,South Korea)

International Email A= ddresses (IEA) are far from the global reality. The current de-facto langua= ge of the Internet is English.  Even today, many of the users of the I= nternet do not speak English as their primary language.  The next bill= ion users of the Internet
are likely to be even less familiar with Engl= ish. IEA is probably the first application needed in a truly internationali= zed Internet.  The Email Address Internationalization (EAI) Working Gr= oup defined the RFCs to support internationalized email.  The time
= may now finally have come to develop best practices and to discuss the dep= loyment challenges for IEA.


Your feedback and suggestions are mo= st welcome to make above cited draft inclusive of all the matters related t= o "Deployment of International Emails.

We may further extend it to t= ake up all the UA related issues.

Hoping for your support.

Th= anks,
Harish Chowdhary

------------------------------------------= ---------------------------------------------------------------------------= ----------
[NIXI is on Social-Media too. Kindly follow us at:
Faceboo= k: https://www.facebook.com/nixiindia & Twitter: @inregistry ]
This = e-mail is for the sole use of the intended recipient(s) and may
contain = confidential and privileged information. If you are not the
intended rec= ipient, please contact the sender by reply e-mail and destroy
all copies= and the original message. Any unauthorized review, use,
disclosure, dis= semination, forwarding, printing or copying of this email
is strictly pr= ohibited and appropriate legal action will be taken.
-------------------= ---------------------------------------------------------------------------= ---



_______________________________________________
IMA m= ailing list
IMA@ietf.org
https://www.ietf.org/mailman/listinfo/ima ------=_Part_365613_43566037.1476460615861-- From nobody Fri Oct 14 09:29:03 2016 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3559129855 for ; Fri, 14 Oct 2016 09:29:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A3lJWSOUrtZi for ; Fri, 14 Oct 2016 09:28:58 -0700 (PDT) Received: from nm27-vm2.bullet.mail.ne1.yahoo.com (nm27-vm2.bullet.mail.ne1.yahoo.com [98.138.91.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82007129548 for ; Fri, 14 Oct 2016 09:28:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1476462538; bh=hkG5rXQHnNWl3pgyF0TilihCRNDVVBHtJP0juQjBbnE=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=rCvqUxGkTkduzoDjG7FcuqHrUdjFO3lB1YKq1NISrRaXe15YVxbgkapuVyyMosBX3YdeQW+mufxEJ43S5dpENQZBavBqFETOJXjtK/83jIdLbLWum5uWK6Chp+dgQDvYWUlLX7/MJB0aTfq4URT3AD+EG2sIy8hbta68VwQBpAqelST5JnohrxuZrphpV/Mi7Jb7r3m8CpOkn4VAmFD5AODHiPAh1DBsNOryn+5Khmj9kBqypOrbwj2EZXyHiu+tQkocA2fDOv9XameCTduzPhjCh7lgEbfESEa6GHQ0jY3GMj0tM6FkuCIN7CziO/OwrB/l17/0W1rFI8/f+F1T8w== Received: from [98.138.100.113] by nm27.bullet.mail.ne1.yahoo.com with NNFMP; 14 Oct 2016 16:28:58 -0000 Received: from [98.138.226.169] by tm104.bullet.mail.ne1.yahoo.com with NNFMP; 14 Oct 2016 16:28:58 -0000 Received: from [127.0.0.1] by omp1070.mail.ne1.yahoo.com with NNFMP; 14 Oct 2016 16:28:58 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 79155.65209.bm@omp1070.mail.ne1.yahoo.com X-YMail-OSG: HdUt53kVM1mAdlbDeJVssVZguO7bOJwf2KYJpQMqv9ld6UlZnULipFFKdcGnQzt RPUYb6ZyriWRSdfmW5loY8gp0Cy2F0qhYtFNBQgeWJpRKgNYY8dv6J5PMzwZgUJ2FeCDKQdCfs3A c91Uk5AwJ8C9Z9iiiHK7veHztdEL.8bUgF8hytf0WSjmAvckMNS09_pcWz8X44._nJXgEUf8e9Jj x09qoKGZEsaIvvuZIF9cqw2Wed21Ta8CyZZJ945NiTAPl.JBe6ojFS.5pmtpvP19JUqy5cyPsZG8 465byYLYdW8_Dh1EthBdSmfaeVn1ljlruqdh_H08khPOqVhHY1oUqcmDM4ep7GQAZtKMmXShnPkG yLPC7y3hfaYeWz8L0VOyLzqChFPzmhd25nSl6u1qlLZ.EewKuQe7hgaR5TQywt3eZQJ9G2vE2YTl kwLPjUZLrfQf17xdIs5HJnJgKZDsVI9GvBSye0z7O9J8c2DzAFTCDbsPpradFYkY_jZsNsEBU0Q7 Wry.oWUnDgCxcrVSZ_39D.haERRVaSU0f9c.wSnYTLiRASo6IBShfGlxCs2PxwOWu Received: from jws200181.mail.ne1.yahoo.com by sendmailws109.mail.ne1.yahoo.com; Fri, 14 Oct 2016 16:28:57 +0000; 1476462537.634 Date: Fri, 14 Oct 2016 16:28:56 +0000 (UTC) From: To: John C Klensin , "HANSEN, TONY L" , "ima@ietf.org" Message-ID: <1130669068.355429.1476462536866@mail.yahoo.com> In-Reply-To: <8B119C286A3CFDE08C598251@JcK-HP8200> References: <20161006055447.32573.qmail@pro-236-157.rediffmailpro.com> <9EC0EB65-9C58-43ED-9A80-1DA32C58E3E0@att.com> <489025644.216489.1476451836537@mail.yahoo.com> <8B119C286A3CFDE08C598251@JcK-HP8200> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_355428_1558044639.1476462536862" Archived-At: Cc: Harish Chowdhary , Peter Saint-Andre Subject: Re: [EAI] General issues and strategy (was: Re: Content Issues [ was: Internationalized Email Internet Draft]) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: nalini.elkins@insidethestack.com List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 16:29:02 -0000 ------=_Part_355428_1558044639.1476462536862 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable John, --On Friday, October 14, 2016 13:30 +0000 nalini.elkins@insidethestack.com wrote: >> John / Tony, >> I am going to split your comments into separate threads so >> that I can keep track of each. =C2=A0=20 >>... >> Yes. =C2=A0I see your point. =C2=A0 Let me say first the basic thing >> that we are trying to do is to discuss the holistic user >> experience of internationalized emails from an operational >> point of view. =C2=A0 In so doing, the co-mingling happened. =C2=A0We >> could do a second draft for content issues or change the >> abstract of this one to better state what our real goal is. >> Secondly, as you guys know well, there are lots of other >> issues with IDN, browser support, etc. =C2=A0 What we were >> actually hoping is that we could have a forum (perhaps like >> DNSOps or v6Ops) where we could come together to define and >> discuss such problems, move towards best practices (or work > arounds! Not that I like that, but it happens.) =C2=A0 Because we >> have not even started on problems that we see such as search >> algorithm ranking of IDNs and so on. =C2=A0 We were hoping that >> others would step up to author such other drafts. >A few very general comments about context.=C2=A0 This might >anticipate some future note from you, so I hope I can get it off >quickly... >(1) I trust you are aware of the ICANN=3D-sponsored "Universal >Acceptance" effort, which is covering some of this same ground. >Personally, I believe they are seriously out in the weeds, doing >a good deal of work on assumptions about the DNS and the EAI >work that are just not valid for a number of technical reasons, >but it would be unfortunate to waste whatever cycles are >associated with duplicative efforts.=C2=A0 As far as I know, Don >Holland is still lead; I think he is on the EAI list but am not >sure. Yes. =C2=A0I am aware of this & want to get Don Holland involved. =C2=A0I s= omehow had the idea he would be in Seoul but maybe I am wrong. =C2=A0I thin= k I will try to have a private conversation with him and Harish ahead of ti= me. >(2) I trust you are also aware that there is an IAB I18N>program.=C2=A0 It= has been, again IMO, fairly unhealthy in the last >couple of years, largely because the available cycles of the >most active and expert people have disappeared into the IANA >Transition activity.=C2=A0 If you want a forum or workshop, they >might be a good place to start.=C2=A0 Ted Hardie is lead; I have no >idea whether he is on the EAI list. I had a very brief conversation with Ted Hardie over email. =C2=A0I will co= ntact him again. >(3) Despite the obvious interest and importance of this issue, I >have observed very little actual energy in the IETF for dealing >with it or i18n issues more generally.=C2=A0 By the time the EAI WG >got its documents out, there was little interest in specific >work beyond "we just want this to work".=C2=A0 By the time the PRECIS >WG got its RFCs out, there was little general interest in >careful review of documents (resulting in a need to start work >on revisions almost immediately thereafter).=C2=A0 AFAICT, the >strongest and most general sentiment in the WG was "just tell me >what to do so I don't need to understand or think about this". >That is understandable, but not a good foundation for getting >work done.=C2=A0 The community has been completely unable to engage >with the "non-decomposing character" issue that has paralyzed >some important IDNA applications for a couple of years now (IMO, >the LUCID BOF, supposedly addressed to that issue, did a good >job of illustrating the more fundamental problems with IETF >engagement, including a lengthy discussion of just how to spell >Z=C3=BCrich in English (or, for that matter, in various versions of >German).=C2=A0=20 >(4) Even among those who were active in the EAI work, there has >been, AFAICT, silence so far except from Tony and myself.=C2=A0 I >know that some are off chasing general equivalence of DNS names. >I believe that effort shows a fundamental lack of understanding >of the properties of the relevant data structures but it seems >to be getting agenda time in Seoul (see "DNSBUNDLED" on Jari's >"New Work in Seoul" BOF list). Sure. =C2=A0I understand your frustration. =C2=A0 Harish and I have been in touch with the community in Africa and Latin Amer= ica as well, as of course, India. =C2=A0 If you will, since this is more of= a problem for the non-English speaking world, then those of us who actuall= y speak languages other than English should step up to the plate and be res= ponsible for doing work. =C2=A0One of the representatives for one of the co= mmunities has told me that they may fund someone to come to Seoul just to w= ork on this project. We have also started a conversation with some of the OS / browser manufactu= rers - the Mozillas and Microsofts of the world. I want to get a core group of maybe 5 - 10 people from various communities = and then people from the OS / browser world. =C2=A0It will take some time t= o get critical mass but as you say, the issue is very critical. =C2=A0That = is definitely being seen at least in the non-Western parts of the world. = =C2=A0(Sorry, I don't know if I am being somehow politically incorrect in p= hrasing this!) I hope that you and Tony can guide us. =C2=A0It will take us some time to c= ome up to speed. =C2=A0It has definitely helped to do a proof of concept im= plementation. =C2=A0Harish and I conference call every week sometimes for t= wo hours to discuss these issues. =C2=A0 We have learned a lot in the past = two months. =C2=A0Mostly based on problems that I have had! We appreciate very much your and Tony's efforts to get the WG and documents= to this stage. =C2=A0But, now we need to work on implementation and migrat= ion issues. =C2=A0 I hope you will be available to guide us. =C2=A0I am not= thinking that we will expect you to be responsible for doing all the work. I was born in India. =C2=A0Many, many of the people in India do not (and ne= ver will) speak English. =C2=A0 Two of the happiest years of my life were l= iving at the edge of the bush in French speaking West Africa. =C2=A0Again, = English was not widely spoken.=C2=A0 But, English is the de-facto language of the Internet. =C2=A0The next billi= on people on the Internet need access in local language. =C2=A0 I think tha= t at the IETF one thing that we can do is quietly and thoughtfully concentr= ate and work out the technical issues. =C2=A0 That is our strength. =C2=A0 = It will take us some time to form a core group. =C2=A0 My hope is that by I= ETF99, we will have enough people to do something interesting. >(5) You should also be sure you understand that many of the >issues with non-ASCII identifiers, especially identifiers=20 Yes. =C2=A0 Are there any RFCs or papers that you might point me to? >(5) If you want rapid deployment of fully-internationalized >email messages, it is important that you understand that there >were alternate hypotheses for how to get both the IDN and that >work done.=C2=A0 For IDNs, we could have changed the DNS and server >matching algorithms (which might have permitted approximate >matching and made a number of issues with comparison and >normalization much easier) or we could have adopted an "above >DNS" model which would have also helped with the matching and >search issues. However, there was a great deal of pressure, some >of it emotional and paralleling the comments about "English" in >your draft, for "fast" and "in the DNS", and that got us the >mappings, restrictions, and trick encoding of IDNA.=C2=A0 Every bit >of new evidence or pressure for synonymous labels and matching >that is predictable given local language culture is an argument >that we got it wrong and should have gone for one of the other >approaches, probably a member of the "Above DNS" family.=C2=A0 For >EAI, there was a similar choice.=C2=A0 We could have stuck with >all-ASCII address local parts and focused on better use of >encoded names (e.g., by making it clear that not copying a name >phrase into a reply or to or from an address book was a very bad >practice, encouraging address book lookups by the name phrase or >equivalent as well as the address, etc., thereby saving a good >many transition and interoperability problems.=C2=A0 I note that was >the solution adopted by the ITU, an organization with far more >representation and influence from countries and people who speak >English as a second language if at all, for a broad range of >I19n issues.=C2=A0 Instead, there was a strong commitment in the WG >and those who pushed for it to have all-non-ASCII mailbox >addresses and to phase out the encoded word approach.=C2=A0 At least >a significant fraction of the WG understood the likely (or >certain) costs of that decision including slow deployment and >interoperability issues that would likely limit EAI use to >"within community" communications.=C2=A0 If, at any point, you want >to argue for discarding SMTPUTF8 and returning to an encoded >word model, there are less difficult (but also less culturally >and aesthetically attractive) ways to move forward. This is very interesting. =C2=A0Let me think it over and we may want to dis= cuss in our core group. =C2=A0 We also need the people from DNS involved. = =C2=A0Let me talk to a few people over there & pick their brains. best, =C2=A0 john >(BTW, as a further illustration of the "too few people with >spare cycles" problem, I'm writing this note rather than working >on the current round of PRECIS revision drafts (and they are, in >turn, holding up work in URNBIS) and am copying Peter, who I >don't think is on the EAI list either, so he knows what is >happening.) John, thank you for everything you have done & for all your help with this. Nalini ------=_Part_355428_1558044639.1476462536862 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
John,

--On Fr= iday, October 14, 2016 13:30 +0000
nalini.elkins@insidethestack.com wrot= e:

>> John / Tony,
>> I am going to split your commen= ts into separate threads so
>> that I can keep track of each. &nbs= p;
>>...
>> Yes.  I see your point.   Let me s= ay first the basic thing
>> that we are trying to do is to discuss= the holistic user
>> experience of internationalized emails from = an operational
>> point of view.   In so doing, the co-mingli= ng happened.  We
>> could do a second draft for content issue= s or change the
>> abstract of this one to better state what our r= eal goal is.
>> Secondly, as you guys know well, there are lots of= other
>> issues with IDN, browser support, etc.   What we we= re
>> actually hoping is that we could have a forum (perhaps like<= br>>> DNSOps or v6Ops) where we could come together to define and
= >> discuss such problems, move towards best practices (or work
>= ; arounds! Not that I like that, but it happens.)   Because we
>= > have not even started on problems that we see such as search
>&g= t; algorithm ranking of IDNs and so on.   We were hoping that
>&= gt; others would step up to author such other drafts.

>A few very= general comments about context.  This might
>anticipate some fu= ture note from you, so I hope I can get it off
>quickly...

>= ;(1) I trust you are aware of the ICANN=3D-sponsored "Universal
>Acce= ptance" effort, which is covering some of this same ground.
>Personal= ly, I believe they are seriously out in the weeds, doing
>a good deal= of work on assumptions about the DNS and the EAI
>work that are just= not valid for a number of technical reasons,
>but it would be unfort= unate to waste whatever cycles are
>associated with duplicative effor= ts.  As far as I know, Don
>Holland is still lead; I think he is= on the EAI list but am not
>sure.

=

Yes.  I am aware of this &a= mp; want to get Don Holland involved.  I somehow had the idea he would= be in Seoul but maybe I am wrong.  I think I will try to have a priva= te conversation with him and Harish ahead of time.


>(2) I trust you are also aware that there is an IAB I18N<= /div>>program.  It has been, again IMO, fairly unhealthy in the las= t
>couple of years, largely because the available cycles of the
&g= t;most active and expert people have disappeared into the IANA
>Trans= ition activity.  If you want a forum or workshop, they
>might be= a good place to start.  Ted Hardie is lead; I have no
>ide= a whether he is on the EAI list.

I had a very brief conversation with Ted Hardie over email.  = ;I will contact him again.


>(3) Despite the obvious interest and importance of this issue, I
&= gt;have observed very little actual energy in the IETF for dealing
>w= ith it or i18n issues more generally.  By the time the EAI WG
>g= ot its documents out, there was little interest in specific
>work bey= ond "we just want this to work".  By the time the PRECIS
>WG got= its RFCs out, there was little general interest in
>careful review o= f documents (resulting in a need to start work
>on revisions almost i= mmediately thereafter).  AFAICT, the
>strongest and most general= sentiment in the WG was "just tell me
>what to do so I don't need to= understand or think about this".
>That is understandable, but not a = good foundation for getting
>work done.  The community has been = completely unable to engage
>with the "non-decomposing character" iss= ue that has paralyzed
>some important IDNA applications for a couple = of years now (IMO,
>the LUCID BOF, supposedly addressed to that issue= , did a good
>job of illustrating the more fundamental problems with = IETF
>engagement, including a lengthy discussion of just how to spell=
>Z=C3=BCrich in English (or, for that matter, in various versions of=
>German). 

>(4) Even among those who were active in = the EAI work, there has
>been, AFAICT, silence so far except from Ton= y and myself.  I
>know that some are off chasing general equival= ence of DNS names.
>I believe that effort shows a fundamental lack of= understanding
>of the properties of the relevant data structures but= it seems
>to be getting agenda time in Seoul (see "DNSBUNDLED" on Ja= ri's
>"New Work in Seoul" BOF list).


Sure.  I understand your frustration.  

Harish and I have been in touch w= ith the community in Africa and Latin America as well, as of course, India.=   If you will, since this is more of a problem for the non-English sp= eaking world, then those of us who actually speak languages other than Engl= ish should step up to the plate and be responsible for doing work.  On= e of the representatives for one of the communities has told me that they m= ay fund someone to come to Seoul just to work on this project.

We have also started a conversation with some o= f the OS / browser manufacturers - the Mozillas and Microsofts of the world= .

I want to get a core= group of maybe 5 - 10 people from various communities and then people from= the OS / browser world.  It will take some time to get critical mass = but as you say, the issue is very critical.  That is definitely being = seen at least in the non-Western parts of the world.  (Sorry, I don't = know if I am being somehow politically incorrect in phrasing this!)

I hope that you an= d Tony can guide us.  It will take us some time to come up to speed. &= nbsp;It has definitely helped to do a proof of concept implementation. &nbs= p;Harish and I conference call every week sometimes for two hours to discus= s these issues.   We have learned a lot in the past two months.  = Mostly based on problems that I have had!

We appreciate very much your and Tony's effo= rts to get the WG and documents to this stage.  But, now we need to wo= rk on implementation and migration issues.   I hope you will be availa= ble to guide us.  I am not thinking that we will expect you to be resp= onsible for doing all the work.

I was born in India.  Many, many of the people in= India do not (and never will) speak English.   Two of the happiest ye= ars of my life were living at the edge of the bush in French speaking West = Africa.  Again, English was not widely spoken. 

But, English is the de-facto= language of the Internet.  The next billion people on the Internet ne= ed access in local language.   I think that at the IETF one thing that= we can do is quietly and thoughtfully concentrate and work out the technic= al issues.   That is our strength.   It will take us some time to= form a core group.   My hope is that by IETF99, we will have enough p= eople to do something interesting.

=
>(5) You should also be sure you understand that many of the
>issues with non-ASC= II identifiers, especially identifiers


=
Yes.   Are there any= RFCs or papers that you might point me to?


>(5) If you want rapid deployment of fully-internatio= nalized
>email messages, it is important that you understand that the= re
>were alternate hypotheses for how to get both the IDN and that>work done.  For IDNs, we could have changed the DNS and server>matching algorithms (which might have permitted approximate
>ma= tching and made a number of issues with comparison and
>normalization= much easier) or we could have adopted an "above
>DNS" model which wo= uld have also helped with the matching and
>search issues. However, t= here was a great deal of pressure, some
>of it emotional and parallel= ing the comments about "English" in
>your draft, for "fast" and "in t= he DNS", and that got us the
>mappings, restrictions, and trick encod= ing of IDNA.  Every bit
>of new evidence or pressure for synony= mous labels and matching
>that is predictable given local language cu= lture is an argument
>that we got it wrong and should have gone for o= ne of the other
>approaches, probably a member of the "Above DNS" fam= ily.  For
>EAI, there was a similar choice.  We could have= stuck with
>all-ASCII address local parts and focused on better use = of
>encoded names (e.g., by making it clear that not copying a name>phrase into a reply or to or from an address book was a very bad
&= gt;practice, encouraging address book lookups by the name phrase or
>= equivalent as well as the address, etc., thereby saving a good
>many = transition and interoperability problems.  I note that was
>the = solution adopted by the ITU, an organization with far more
>represent= ation and influence from countries and people who speak
>English as a= second language if at all, for a broad range of
>I19n issues.  = Instead, there was a strong commitment in the WG
>and those who push= ed for it to have all-non-ASCII mailbox
>addresses and to phase out t= he encoded word approach.  At least
>a significant fraction of t= he WG understood the likely (or
>certain) costs of that decision incl= uding slow deployment and
>interoperability issues that would likely = limit EAI use to
>"within community" communications.  If, at any= point, you want
>to argue for discarding SMTPUTF8 and returning to a= n encoded
>word model, there are less difficult (but also less cultur= ally
>and aesthetically attractive) ways to move forward.


This is very interesting.  Let me think it over and we ma= y want to discuss in our core group.   We also need the people from DN= S involved.  Let me talk to a few people over there & pick their b= rains.

best,
  john


>(BTW, as a further illustration of th= e "too few people with
>spare cycles" problem, I'm writing this note = rather than working
>on the current round of PRECIS revision drafts (= and they are, in
>turn, holding up work in URNBIS) and am copying Pet= er, who I
>don't think is on the EAI list either, so he knows what is=
>happening.)

John, than= k you for everything you have done & for all your help with this.
=

Nalini

------=_Part_355428_1558044639.1476462536862-- From nobody Fri Oct 14 09:34:46 2016 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD6A3129867 for ; Fri, 14 Oct 2016 09:34:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.896 X-Spam-Level: X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4oT2n6LUOOFG for ; Fri, 14 Oct 2016 09:34:42 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B1A8129864 for ; Fri, 14 Oct 2016 09:34:42 -0700 (PDT) Received: from [198.252.137.10] (helo=JcK-HP8200) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1bv5RO-000B2n-8l; Fri, 14 Oct 2016 12:34:38 -0400 Date: Fri, 14 Oct 2016 12:34:33 -0400 From: John C Klensin To: nalini.elkins@insidethestack.com, "HANSEN, TONY L" , ima@ietf.org Message-ID: In-Reply-To: <1600128477.303347.1476456552432@mail.yahoo.com> References: <20161006055447.32573.qmail@pro-236-157.rediffmailpro.com> <9EC0EB65-9C58-43ED-9A80-1DA32C58E3E0@att.com> <1600128477.303347.1476456552432@mail.yahoo.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: klensin@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: Harish Chowdhary Subject: Re: [EAI] [IETF] Display of Email Addresses [was: Internationalized Email Internet Draft] X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 16:34:45 -0000 --On Friday, October 14, 2016 14:49 +0000 nalini.elkins@insidethestack.com wrote: > John / Tony, >=20 > Continuing my splitting of topics! =C2=A0 Hope this makes some > kind of sense to others. >> By contrast, Section 1.1 talks about display of email >> addresses,=C2=A0including the local part ("in Punycode" = [2]).=C2=A0 >> While a mail=C2=A0delivery server is free to create whatever >> aliases for a ?>mailbox=C2=A0local part it likes, including >> "xn-t2bmh3a" or "123456",=C2=A0"george" or "example", in = general >> converting a local part using=C2=A0the Punycode algorithm and >> displaying the result is >prohibited=C2=A0by the EAI = standards >> (and, incidentally, RFC5321).=C2=A0 More=C2=A0important, it = will >> often lose information and is potentially=C2=A0very = dangerous. > This is a very interesting problem. =C2=A0 We are hoping to do > some kind of spreadsheet or other visual where we can show > what happens with a number of mail servers. =C2=A0For example, > what does Yahoo mail do, what does gmail do,=C2=A0why some = clients > fail,=C2=A0etc.=20 I am glad to see another one, but note that this was done with what was then available before the Beijing workshop, that something similar has been done (or claimed to be done) in the "Universal Acceptance" group (see below), and maybe elsewhere. You also need to be very careful about the tests you run. For example, on delivery and when referring to its own (virtual) mailbox names, gmail apparently discards some or all ASCII delimiter characters in local parts, treating local parts containing such characters as equivalent to ones with the characters dropped. I have no idea what they do with delimiter characters from other scripts, but some other systems would consider that delimiter-dropping behavior pathological or worse. A different way of looking at that is that they are preserving the local parts but dropping certain characters in mapping from mailbox name to actual storage. Either is fine with the protocols as long as the computational aliasing is done only at or beyond the delivery server. =20 There are also a large number of issues at the boundaries between email and HTML/HTTP that affect many implementations that fail to account for the differences. That problem, and to some extent the gmail behavior above, are examples of another situation we see quite often: the problems are there even in all-ASCII strings and identifiers, i18n simply amplifies them and makes them more obvious. >=C2=A0 I am in the process of setting up a demo system > for all this. =C2=A0Let me tell you, I have learned quite a = bit. Sadly, I am not surprised. I am also not surprised if a good deal of what you have learned has been painful. It certainly has been for many of the rest of us. I think it is also important to keep in mind that most of the underlying issues are ultimately the result of variations and evolution in human language and writing systems. Some of the decisions we have made in the IETF, and that the Unicode Consortium has made, have made some issues harder and some easier but, as long as we want to deal with the full range of human languages and writing systems, most of the problems are inherent and the choices end up being about compromises (or, if you prefer, winners and losers). Some of the relationships are rather old. For example, rather explicit decisions were made many centuries ago that Latin and Chinese characters should be easily distinguishable by people with some familiarity with them but without necessarily being literate. Latin ended up with a lower familiarity requirement by having very few characters; Chinese ended up with many characters and the advantages of a single writing system that could express meaning of many languages, even ones that are mutually incomprehensible while Rome took the approach that everyone should simply learn Latin. That makes the two scripts special even though some evolution to both in more recent centuries has muddied the distinguishability somewhat. > =C2=A0 Including about DNS queries which don't resolve = properly. > =C2=A0Sigh. =C2=A0That is still ANOTHER topic. =C2=A0 As I = say, I want to > get organized and have a good way to show this. =C2=A0 Not = quite > there yet! =C2=A0 See Andrew's comment (and my earlier one) about the Universal Acceptance effort. But I suggest you need to go further than reaching out to them. The sad reality is that there are very few people in the Internet (not just IETF) community with a good understanding of email protocols and operations, DNS and IDNA protocols and operations, writing systems and character coding including the many writing system issues that have nothing to do with character coding, and Unicode operations. On many days, I'm not even sure I'm part of that rather small group. Most of us are willing to try to explain issues to others, but only to those who want to put the energy into listening and learning, not just saying thing that amount to "as long as I think it works for my language, everything else is fine" or "just tell me what to do because I have no intention of learning or thinking about the issues". That expertise is spread sufficiently thin that answering a question or reviewing a document in one places causes something else to be delayed or not happen (e.g., as mentioned earlier, responding to your notes, which I considered important, has retarded progress on both PRECIS and URNBIS work for several days). So there are extremely pragmatic reasons for you to try to either merge your work into the Universal Acceptance effort (or vice versa) or to establish really clear boundaries between the two. And that is probably all the time I can put in on this today. best, john From nobody Fri Oct 14 09:54:00 2016 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF77E127077 for ; Fri, 14 Oct 2016 09:53:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.317 X-Spam-Level: X-Spam-Status: No, score=-7.317 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=linkedin.com header.b=ANP+pX8F; dkim=pass (1024-bit key) header.d=linkedin.com header.b=hSc/AEbT Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cl0Z11sUoPPa for ; Fri, 14 Oct 2016 09:53:54 -0700 (PDT) Received: from mail522.linkedin.com (mail522.linkedin.com [108.174.6.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4683A129505 for ; Fri, 14 Oct 2016 09:53:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; s=proddkim1024; t=1476464032; bh=N1hIlkCaWXgvmfmM63KD5MkpGnEVlmFsZ7P+KfxhTu0=; h=MIME-Version:From:Date:Subject:To:Content-Type; b=ANP+pX8FVddfOdQdzGkTVhrxm2RdcmkvkBl9B152kgOGkwVTb+qsNvaoTADK3yNtz aeWxd9oeEt+FEIf4qf9kYfR8aSC/3Tu6Lr2IER+rOwkNq+TEir/kwDZ82GlDIEsf2/ RleN6/7mcaHIMI0xvB93lBXATd+QxjFZ+uiifXrY= Authentication-Results: mail522.prod.linkedin.com x-tls.subject="/C=US/ST=California/L=Mountain View/O=Google Inc/CN=smtp.gmail.com"; auth=pass (cipher=ECDHE-RSA-AES128-GCM-SHA256) Authentication-Results: mail522.prod.linkedin.com; iprev=pass policy.iprev="2607:f8b0:400d:c0d::248"; spf=softfail smtp.mailfrom="fmartin@linkedin.com" smtp.helo="mail-qt0-x248.google.com"; dkim=pass header.d=linkedin.com; tls=pass (verified) key.ciphersuite="TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256" key.length="128" tls.v="tlsv1.2" cert.client="C=US,ST=California,L=Mountain View,O=Google Inc,CN=smtp.gmail.com" cert.clientissuer="C=US,O=Google Inc,CN=Google Internet Authority G2" Received: from [2607:f8b0:400d:c0d::248] ([2607:f8b0:400d:c0d::248.33473] helo=mail-qt0-x248.google.com) by mail522.prod.linkedin.com (envelope-from ) (ecelerity 3.6.21.53563 r(Core:3.6.21.0)) with ESMTPS (cipher=ECDHE-RSA-AES128-GCM-SHA256 subject="/C=US/ST=California/L=Mountain View/O=Google Inc/CN=smtp.gmail.com") id 58/17-11653-0AD01085; Fri, 14 Oct 2016 16:53:52 +0000 Received: by mail-qt0-x248.google.com with SMTP id z54so81432897qtz.0 for ; Fri, 14 Oct 2016 09:53:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=N1hIlkCaWXgvmfmM63KD5MkpGnEVlmFsZ7P+KfxhTu0=; b=hSc/AEbTpcIW5cTR59hXxFtP2QPnOy3afa4HO4Tm06cZYK2zZQNzgOR9d724BfoCzO hSBq56nzzUpJo+GnknhlMZtnFAGpw8jU4Dqbh8NFFhyaZswMU7G+8G651l+G+43luV/4 l1iwAa444fv2uQGZXaivKkKh+GFEUydhViz2w= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=N1hIlkCaWXgvmfmM63KD5MkpGnEVlmFsZ7P+KfxhTu0=; b=L20c7fDWPL4Sk4ZtJVggGVcrmSwJn74iaCeWBu1fqhc7ufw7PjK9N2FUQcV2ST24un fkYa+CkAwRXReIYVXL5x/fdO7vM8t5r2wlEUn+2/mImLBd6J+Qwr3FLRgc4RbUj3jiI4 STmm3MEI1ayjZO21s8Bt/a6VQanFfKCJEopJ2ohATkuZfhtmEDnqy1ECuNYSGFNtN3lf 0eTRoSYodDttS1uMBCoBDSZ4eYuROV5xKRL+7u7y9pSGoQz6rXpP6jbDOyauEQUeXLNy eXLv7YGjff4P3e712C5TjR3JhpuKUg27YieMJXgNdpJ8KoJKaRWIZyBe4SWzktWqOXsk 2g2Q== X-Gm-Message-State: AA6/9RlRu3RQN5WUTr0nasJOPZDj1lx3MlKgNdnko+WtZ5Qt5mRY0JHjjEOLXHevaNG8frkIHjmbiE4vyge2Bk/6nKQLlLD991BGKgCwCloLZCFIjN4SxDrfbelTRKYSBC7CAfUpyWA5r/Dr3aPTLAv88w== X-Received: by 10.55.163.214 with SMTP id m205mr12168741qke.68.1476464018518; Fri, 14 Oct 2016 09:53:38 -0700 (PDT) X-Received: by 10.55.163.214 with SMTP id m205mr12168717qke.68.1476464018175; Fri, 14 Oct 2016 09:53:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.95.84 with HTTP; Fri, 14 Oct 2016 09:53:17 -0700 (PDT) In-Reply-To: <489025644.216489.1476451836537@mail.yahoo.com> References: <20161006055447.32573.qmail@pro-236-157.rediffmailpro.com> <9EC0EB65-9C58-43ED-9A80-1DA32C58E3E0@att.com> <489025644.216489.1476451836537@mail.yahoo.com> From: Franck Martin Date: Fri, 14 Oct 2016 09:53:17 -0700 Message-ID: To: nalini.elkins@insidethestack.com Content-Type: multipart/alternative; boundary=94eb2c070a8453df7c053ed61105 Archived-At: Cc: Harish Chowdhary , "ima@ietf.org" Subject: Re: [EAI] [IETF] Content Issues [ was: Internationalized Email Internet Draft] X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 16:53:58 -0000 --94eb2c070a8453df7c053ed61105 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I tried to subscribe to this list using my email address =E5=BC=97=E5=85=B0= =E5=85=8B@=E4=BA=92=E8=81=94=E7=BD=91.=E5=85=AC=E5=8F=B8 but mailman replied: Your subscription is not allowed because the email address you gave is insecure. On Fri, Oct 14, 2016 at 6:30 AM, wrote: > John / Tony, > > I am going to split your comments into separate threads so that I can kee= p > track of each. The first is about co-mingling content vs. headers. > > >(1) The so-called EAI standards, as listed in the Introduction, are > about email envelope and header information presented directly (e.g., in > UTF-8) as non-ASCII characters. A good deal of the document appears to > address mail >content information such as textual message bodies, in > other scripts. With the possible exception of language selection when a > message is sent with the same basic text in several languages > (multipart/alternative was designed with >that case in mind but have been > used in other ways), we thought we solved that content problem with MIME > in 1992. If MIME is inadequate, the authors or others should produce a > document explaining the issues and not confuse >them with EAI / > SMTPUTF8. If it is adequate, then, like Tony although perhaps for > different reasons, I don't see what Section 1.2 is doing here, what the > relevance of Section 3.2 is, and several other statements should be > examined >carefully to be sure they are talking about addresses and/or > headers and not content. > > Yes. I see your point. Let me say first the basic thing that we are > trying to do is to discuss the holistic user experience of > internationalized emails from an operational point of view. In so doing= , > the co-mingling happened. We could do a second draft for content issues = or > change the abstract of this one to better state what our real goal is. > > Secondly, as you guys know well, there are lots of other issues with IDN, > browser support, etc. What we were actually hoping is that we could hav= e > a forum (perhaps like DNSOps or v6Ops) where we could come together to > define and discuss such problems, move towards best practices (or work > arounds! Not that I like that, but it happens.) Because we have not eve= n > started on problems that we see such as search algorithm ranking of IDNs > and so on. We were hoping that others would step up to author such othe= r > drafts. > > > Thanks, > > Nalini Elkins > Inside Products, Inc. > www.insidethestack.com > (831) 659-8360 > > > ------------------------------ > *From:* John C Klensin > *To:* "HANSEN, TONY L" ; ima@ietf.org > *Sent:* Sunday, October 9, 2016 7:57 PM > *Subject:* Re: [EAI] [IETF] Internationalized Email Internet Draft > > > > --On Thursday, October 06, 2016 4:39 PM +0000 "HANSEN, TONY L" > wrote: > > > I think getting deployment feedback from EAI is important, and > > this draft is an excellent start. > > > > I'm not convinced that section 1.2 describes a real problem. > > People do this all the time today with various combinations of > > languages. Why is the combination of Russian and Chinese any > > different? If you think it is, then please expand on the > > aspect that does make it more difficult. > > > > I forwarded a number of nits to the authors. > > Hi. I was going to hold off until some later and more mature > version of this draft, but since Tony has commented, while I > believe the issues with EAI deployment are important, I see > several problems with this draft, some of which were actually > discussed in the WG but appear to be ignored here. Perhaps more > important, it is seriously incomplete relative to issues that > have been discussed at great length in the EAI WG, at the APEC > meeting on internationalized email in Beijing in October 2014, > the May 2015 workshop in Thailand, and elsewhere. I strongly > suggest that, if there is going to be a discussion in Seoul, > this document is in need of a great deal of work first. Some of > those issues are: > > (1) The so-called EAI standards, as listed in the Introduction, > are about email envelope and header information presented > directly (e.g., in UTF-8) as non-ASCII characters. A good deal > of the document appears to address mail content information such > as textual message bodies, in other scripts. With the possible > exception of language selection when a message is sent with the > same basic text in several languages (multipart/alternative was > designed with that case in mind but have been used in other > ways), we thought we solved that content problem with MIME in > 1992. If MIME is inadequate, the authors or others should > produce a document explaining the issues and not confuse them > with EAI / SMTPUTF8. If it is adequate, then, like Tony > although perhaps for different reasons, I don't see what Section > 1.2 is doing here, what the relevance of Section 3.2 is, and > several other statements should be examined carefully to be sure > they are talking about addresses and/or headers and not content. > > (2) Within an address, there is, as the I-D points out and > consistent with RFC 5321, a local part and a domain part. RFCs > 6530 and 6531 make it quite clear (at least we thought they did) > that they are handled differently. For the domain part, the > rules are laid out in the IDNA2008 specs (RFC 5890ff). Issues > about look-alike characters have been extensively discussed and > written about (even though some of us have questioned the > quality of some of that work). It does not seem useful to me to > revisit those issues here, especially without reference to the > prior work and discussions or if some of the discussion here is > wrong or contains obvious omissions. As an example from the > first paragraph of Section 6.1, Latin "c" (U+0063) and Cyrillic > "c" (U+0441) are typically written with identical graphemes, but > are not on the list. More important, while the "paypal" > example with U+0430 substituted for "a" (U+0061) has been used > repeatedly, including in a careful study in an article that is > not cited in this draft, it is possible to write "=D1=80=D0=B0=D1=83=D1= =80=D0=B01" > with the first five characters in Cyrillic and the last one a > digit (which is script independent) > (\u'0440'\u'0430'\u'0443'\u'0440'\u'040'\u'0031' [1]), therefore > not even violating conventions prohibiting mixed-script labels. > There is, of course, no ambiguity in the A-label form, although > the authors quite properly point out that it is not > user-friendly. > > By contrast, Section 1.1 talks about display of email addresses, > including the local part ("in Punycode" [2]). While a mail > delivery server is free to create whatever aliases for a mailbox > local part it likes, including "xn-t2bmh3a" or "123456", > "george" or "example", in general converting a local part using > the Punycode algorithm and displaying the result is prohibited > by the EAI standards (and, incidentally, RFC5321). More > important, it will often lose information and is potentially > very dangerous. > > (3) Arabic should not be confused with a strictly right-to-left > writing system. I am not aware of any such systems in wide use > for contemporary languages today. The problem is that numerals, > whether written in European digits, Arabic or Arabic-Indic > digits, Chinese (Han) digits, or many others, have been written > left to right since that type of positional notation was > invented and became widely used. As a result, the scripts are > referred to (in Unicode-speak) as "bidirectional" or "bidi" [3]. > Their implications for domain names and IDNA are the subject of > RFC 5893. > > (4) Multiple addresses for one user (and Section 4). Keeping in > mind that many people maintain a number of identities, and even > multiple email addresses, for different purposes, I don't > understand what point you are trying to make with this section. > Many of us believe that users who have mailboxes whose names > involve non-ASCII local parts and who engage in communications > outside their primary language group will find it necessary to > maintain either separate all-ASCII mailboxes or all-ASCII > aliases to their primary mailboxes and to do so for a very long > time. That issue has been extensively analyzed and discussed > but this document avoids that work, which is both a problem and > an opportunity. > > (5) Section 2.1 asserts that email servers), implying all of > them, store data (messages?) in relational databases. That is > simply false. Some do; others don't. Even for those that do, > there may be a difference between Unicode-capable data storage > and Unicode-capable keys or indexes. There is also absolutely > no requirement that any such system store Unicode strings > encoded in UTF-8; many do not. > > (6) There is a necessary difficulty with SMTPUTF8, which is that > one cannot transmit a message with non-ASCII characters in > addresses or headers to a system that does not support them. > Final delivery systems should probably not accept messages > unless they have reason to predict that the mail store will > handle them _and_ that the user associated with the target > mailbox will be able to retrieve them. Since a user with an > all-ASCII mailbox name might still receive a message with, e.g., > a non-ASCII backward-pointing address in the envelope or > headers, making that decision is not straightforward. That > leads to a strong case that, if one wants broad deployment of > SMTPUTF8, the place to start is with the MUAs (including the > Webmail systems) and associated POP and IMAP servers and > clients. The "to various extents" list in the first part of > Section 3 is not particularly helpful in that regard. > > (7) Finally, this is an internationalization (i18n) problem as > much as it is an email problem. Terminology (and, where > characters or code points are referred to, their precise > identification) is very important because the alternative is > typically a good deal of user confusion about what you are > talking about and other impediments to making progress. Saying > "English" were you mean "Basic Latin Script" or "ASCII" is not > helpful, especially given that 5321 local parts can include any > ASCII character and that ASCII is not sufficient to write > English. Conversely, it appears that there are a few places > where, correctly or incorrectly, you really do mean "English" > when you say that. Similarly, talking about one particular > encoding when you mean "Unicode" is confusing and may be > misleading. RFC 6365 may give you a start on some of the issues. > > regards, > john > > > ------------- > [1] I recommend the authors have a look at RFC 5137. > > [2] Punycode is an encoding method, not a display format. See > RFC 5890, Section 2.3.4. > > [3] http://unicode.org/reports/tr9/ > > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima > > > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima > > --94eb2c070a8453df7c053ed61105 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I tried to subscribe to this list using my email address= =C2=A0=E5=BC=97=E5=85=B0=E5=85=8B@=E4=BA=92=E8=81=94=E7=BD=91.=E5=85=AC=E5= =8F=B8 but mailman replied:=C2=A0

Your subscription is not allo= wed because the email address you gave is insecure.
<= div class=3D"gmail_extra">
On Fri, Oct 14, 20= 16 at 6:30 AM, <nalini.elkins@insidethestack.com> wrote:
<= div dir=3D"ltr" id=3D"m_6982630020831200489yui_3_16_0_ym19_1_1476450906229_= 5781">John / Ton= y,

=
I am going to split your comments into separate threads so that I can k= eep track of each. =C2=A0 The first is about co-mingling content vs. header= s.

>(1) The so-called EAI standards, as listed in t= he Introduction,=C2=A0are about email envelope and header information presented=C2= =A0direct= ly (e.g., in UTF-8) as non-ASCII characters.=C2=A0 A good deal=C2=A0= of the document = appears to address mail >content information such=C2=A0as textual message bodies,= in other scripts.=C2=A0 With the possible=C2=A0exception of language selection when= a message is sent with the=C2=A0same basic text in several languages (multipart/alt= ernative was=C2=A0designed with >that case in mind but have been used in other=C2= =A0ways),= we thought we solved that content problem with MIME in=C2=A01992.=C2=A0 If MIME is = inadequate, the authors or others should=C2=A0produce a document explaining the issu= es and not confuse >them=C2=A0with EAI / SMTPUTF8.=C2=A0 If it is adequate, then,= like Tony=C2=A0although perhaps for different reasons, I don't see what Section= =C2=A01.2= is doing here, what the relevance of Section 3.2 is, and=C2=A0several other stateme= nts should be examined >carefully to be sure=C2=A0they are talking about addresse= s and/or headers and not content.

Yes.=C2=A0 I see your point. =C2=A0 Let me say first the basi= c thing that we are trying to do is to discuss the holistic user experience o= f internationalized emails from an operational point of view. =C2=A0 In so = doing, the co-mingling happened.=C2=A0 We could do a second draft for conte= nt issues or change the abstract of this one to better state what our real = goal is.

Secondly= , as you guys know well, there are lots of other issues with IDN, browser s= upport, etc. =C2=A0 What we were actually hoping is that we could have a fo= rum (perhaps like DNSOps or v6Ops) where we could come together to define a= nd discuss such problems, move towards best practices (or work arounds! Not= that I like that, but it happens.) =C2=A0 Because we have not even started= on problems that we see such as search algorithm ranking of IDNs and so on= . =C2=A0 We were hoping that others would step up to author such other draf= ts.

=C2=A0
Thanks,

Nalini Elkins


<= b>From: John C Klensin <klensin@jck.com> To: "HANSEN, TONY L&q= uot; <tony@att.com= >; ima@ietf.org Sent: Sunday, October 9, = 2016 7:57 PM
Subject: Re= : [EAI] [IETF] Internationalized Email Internet Draft


--On Thursday, October 06, 2016 4:39 PM +0000 "HANSEN= , TONY L"
<tony@att.com> wrote:
> I think getting deployment feedback from EAI is impor= tant, and
> this draft is an excellent start.
>
> I'm not convinced that section 1= .2 describes a real problem.
> People do this all the = time today with various combinations of
> languages. W= hy is the combination of Russian and Chinese any
> dif= ferent? If you think it is, then please expand on the
>= ; aspect that does make it more difficult.
>
> I forwarded a number of nits to the authors.

Hi.=C2=A0 I was going to hold off until some later an= d more mature
version of this draft, but since Tony has c= ommented, while I
believe the issues with EAI deployment = are important, I see
several problems with this draft, so= me of which were actually
discussed in the WG but appear = to be ignored here.=C2=A0 Perhaps more
important, it is s= eriously incomplete relative to issues that
have been dis= cussed at great length in the EAI WG, at the APEC
meeting= on internationalized email in Beijing in October 2014,
t= he May 2015 workshop in Thailand, and elsewhere.=C2=A0 I strongly
suggest that, if there is going to be a discussion in Seoul,
this document is in need of a great deal of work first.=C2=A0= Some of
those issues are:

(1) The so-called EAI standards, as listed in the Introduction,
are about email envelope and header information presented
directly (e.g., in UTF-8) as non-ASCII characters.=C2=A0 A g= ood deal
of the document appears to address mail content = information such
as textual message bodies, in other scri= pts.=C2=A0 With the possible
exception of language select= ion when a message is sent with the
same basic text in se= veral languages (multipart/alternative was
designed with = that case in mind but have been used in other
ways), we t= hought we solved that content problem with MIME in
1992.= =C2=A0 If MIME is inadequate, the authors or others should
produce a document explaining the issues and not confuse them
with EAI / SMTPUTF8.=C2=A0 If it is adequate, then, like Tony
although perhaps for different reasons, I don't see what Se= ction
1.2 is doing here, what the relevance of Section 3.= 2 is, and
several other statements should be examined car= efully to be sure
they are talking about addresses and/or= headers and not content.

(2) Within a= n address, there is, as the I-D points out and
consistent= with RFC 5321, a local part and a domain part.=C2=A0 RFCs
6530 and 6531 make it quite clear (at least we thought they did)
that they are handled differently.=C2=A0 For the domain part, the=
rules are laid out in the IDNA2008 specs (RFC 5890ff).= =C2=A0 Issues
about look-alike characters have been exten= sively discussed and
written about (even though some of u= s have questioned the
quality of some of that work).=C2= =A0 It does not seem useful to me to
revisit those issues= here, especially without reference to the
prior work and= discussions or if some of the discussion here is
wrong o= r contains obvious omissions.=C2=A0 As an example from the
first paragraph of Section 6.1, Latin "c" (U+0063) and Cyrillic=
"c" (U+0441) are typically written with identi= cal graphemes, but
are not on the list.=C2=A0 =C2=A0 More= important, while the "paypal"
example with U+0= 430 substituted for "a" (U+0061) has been used
= repeatedly, including in a careful study in an article that is
not cited in this draft, it is possible to write "=D1=80=D0=B0= =D1=83=D1=80=D0=B01"
with the first five characters = in Cyrillic and the last one a
digit (which is script ind= ependent)
(\u'0440'\u'0430'\u'0443= 9;\u'0440'\u'040'\u'0031' [1]), therefore
not even violating conventions prohibiting mixed-script label= s.
There is, of course, no ambiguity in the A-label form,= although
the authors quite properly point out that it is= not
user-friendly.

= By contrast, Section 1.1 talks about display of email addresses,
including the local part ("in Punycode" [2]).=C2=A0 Whi= le a mail
delivery server is free to create whatever alia= ses for a mailbox
local part it likes, including "xn= -t2bmh3a" or "123456",
"george" = or "example", in general converting a local part using
the Punycode algorithm and displaying the result is prohibitedby the EAI standards (and, incidentally, RFC5321).=C2=A0 Mo= re
important, it will often lose information and is poten= tially
very dangerous.

(3) Arabic should not be confused with a strictly right-to-left
writing system.=C2=A0 I am not aware of any such systems in wide = use
for contemporary languages today.=C2=A0 The problem i= s that numerals,
whether written in European digits, Arab= ic or Arabic-Indic
digits, Chinese (Han) digits, or many = others, have been written
left to right since that type o= f positional notation was
invented and became widely used= .=C2=A0 As a result, the scripts are
referred to (in Unic= ode-speak) as "bidirectional" or "bidi" [3].
Their implications for domain names and IDNA are the subject ofRFC 5893.

(4) Multipl= e addresses for one user (and Section 4).=C2=A0 Keeping in
mind that many people maintain a number of identities, and even
multiple email addresses, for different purposes, I don't
understand what point you are trying to make with this secti= on.
Many of us believe that users who have mailboxes whos= e names
involve non-ASCII local parts and who engage in c= ommunications
outside their primary language group will f= ind it necessary to
maintain either separate all-ASCII ma= ilboxes or all-ASCII
aliases to their primary mailboxes a= nd to do so for a very long
time.=C2=A0 That issue has be= en extensively analyzed and discussed
but this document a= voids that work, which is both a problem and
an opportuni= ty.

(5) Section 2.1 asserts that email= servers), implying all of
them, store data (messages?) i= n relational databases.=C2=A0 That is
simply false.=C2=A0= Some do; others don't.=C2=A0 Even for those that do,
there may be a difference between Unicode-capable data storage
and Unicode-capable keys or indexes.=C2=A0 There is also absolut= ely
no requirement that any such system store Unicode str= ings
encoded in UTF-8; many do not.=C2=A0

(6) There is a necessary difficulty with SMTPUTF8, w= hich is that
one cannot transmit a message with non-ASCII= characters in
addresses or headers to a system that does= not support them.
Final delivery systems should probably= not accept messages
unless they have reason to predict t= hat the mail store will
handle them _and_ that the user a= ssociated with the target
mailbox will be able to retriev= e them.=C2=A0 Since a user with an
all-ASCII mailbox name= might still receive a message with, e.g.,
a non-ASCII ba= ckward-pointing address in the envelope or
headers, makin= g that decision is not straightforward.=C2=A0 That
leads = to a strong case that, if one wants broad deployment of
S= MTPUTF8, the place to start is with the MUAs (including the
Webmail systems) and associated POP and IMAP servers and
clients.=C2=A0 The "to various extents" list in the first par= t of
Section 3 is not particularly helpful in that regard= .

(7) Finally, this is an internationa= lization (i18n) problem as
much as it is an email problem= .=C2=A0 Terminology (and, where
characters or code points= are referred to, their precise
identification) is very i= mportant because the alternative is
typically a good deal= of user confusion about what you are
talking about and o= ther impediments to making progress.=C2=A0 Saying
"E= nglish" were you mean "Basic Latin Script" or "ASCII&qu= ot; is not
helpful, especially given that 5321 local part= s can include any
ASCII character and that ASCII is not s= ufficient to write
English.=C2=A0 Conversely, it appears = that there are a few places
where, correctly or incorrect= ly, you really do mean "English"
when you say t= hat.=C2=A0 Similarly, talking about one particular
encod= ing when you mean "Unicode" is confusing and may be
misleading.=C2=A0 RFC 6365 may give you a start on some of the issues.=

regards,
=C2=A0 =C2= =A0 john


=C2=A0 ---= ----------
[1] I recommend the authors have a look at RFC= 5137.

[2] Punycode is an encoding met= hod, not a display format.=C2=A0 See
RFC 5890, Section=C2= =A0 2.3.4.

[3] http://unicode.org/r= eports/tr9/


___= ____________________________________________
IMA mai= ling list
IMA@ietf.org
https://ww= w.ietf.org/mailman/listinfo/ima



_______________________________________________
IMA mailing list
IMA@ietf.org
https://www.ietf.org/mailman/listinfo/ima


--94eb2c070a8453df7c053ed61105-- From nobody Fri Oct 14 17:21:41 2016 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 804EA1293FC for ; Fri, 14 Oct 2016 17:21:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.896 X-Spam-Level: X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VjoEXTV7TdsB for ; Fri, 14 Oct 2016 17:21:37 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48313124281 for ; Fri, 14 Oct 2016 17:21:37 -0700 (PDT) Received: from [198.252.137.10] (helo=JcK-HP8200) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1bvCjA-000E48-Bo; Fri, 14 Oct 2016 20:21:28 -0400 Date: Fri, 14 Oct 2016 20:21:23 -0400 From: John C Klensin To: Franck Martin , nalini.elkins@insidethestack.com Message-ID: <858075347E9E1284B621875B@JcK-HP8200> In-Reply-To: References: <20161006055447.32573.qmail@pro-236-157.rediffmailpro.com> <9EC0EB65-9C58-43ED-9A80-1DA32C58E3E0@att.com> <489025644.216489.1476451836537@mail.yahoo.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: Harish Chowdhary , ima@ietf.org Subject: Re: [EAI] [IETF] Content Issues [ was: Internationalized Email Internet Draft] X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Oct 2016 00:21:39 -0000 --On Friday, October 14, 2016 09:53 -0700 Franck Martin wrote: > I tried to subscribe to this list using my email address > = =E5=BC=97=E5=85=B0=E5=85=8B@=E4=BA=92=E8=81=94=E7=BD=91.=E5=85=AC= =E5=8F=B8 but mailman replied: >=20 > Your subscription is not allowed because the email address you > gave is insecure. Franck, First and most important, the IETF mail servers, or at least ietfa.amsl.com, do not advertise SMTPUTF8 as a capability. So, given the issues discussed in RFC 6783 and elsewhere, it would be really stupid for the IETF version of mailman to accept a non-ASCII address. =20 One can debate whether, under the "eat our own dogfood" principle or something else, the IETF mail servers should be SMTPUTF8-capable and advertising that extension. I encourage anyone who feels strongly that the servers should support SMTPUTF8 at this time to take it up with the IESG and/or IAOC, or, perhaps even better, to try some extended rants during the Seoul plenary, perhaps delivering those rants in multiple languages that none of the IESG, IAOC, or IAB understand. That would help to make the point about how full SMTPUTF8 support within IETF discussion lists would facilitate communication and diversity. Seriously, at least in the near term, I'd oppose letting anyone post to an IETF list from a non-ASCII address. This has been discussed before in other contexts, but it is important that we, as a standards body, be able to identify who is posting to our lists and trying to influence outcomes. The IETF possibly doesn't go far enough in that direction -- again, a topic that has been discussed before. At least as long as we do our business in English and don't have authoritative translations to and from any other accepted languages of just about everything available, we should stick to addresses that everyone who participates here (in English) can read. I'm belaboring this point only because the special issues involving mailing lists, especially mailing lists whose membership/recipients may involve people from more than one language group, are yet another issue that has to be considered carefully on the way to a world that is fully SMTPUTF8-enabled. best, john From nobody Sat Oct 15 18:00:36 2016 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F15A21294AC for ; Sat, 15 Oct 2016 18:00:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.104 X-Spam-Level: X-Spam-Status: No, score=-0.104 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P4o8Z5TBMZiz for ; Sat, 15 Oct 2016 18:00:34 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0104.outbound.protection.outlook.com [104.47.42.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97821129493 for ; Sat, 15 Oct 2016 18:00:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=wpfbvVI4Gw1AHX8EqmpBvycFDYXPJ1tKWdTfW++hCPM=; b=EsSSew+kV2bStb6hNnBGM2ZIlsLuJ5dyuDXGx0f0OZkzjq872Krgy9O7Jdfb/8FzxVsHHiZKKXvkLhrG15PbQiC9kqIISsxAdoDt8v5VxRQkus7757KdEt9W9mR0GbCkkw+KhEnMrj0iqwonhlscaDajvZFe97i8Sk5qjq7TTnU= Received: from MWHPR03MB2813.namprd03.prod.outlook.com (10.175.135.7) by MWHPR03MB2813.namprd03.prod.outlook.com (10.175.135.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.659.11; Sun, 16 Oct 2016 01:00:33 +0000 Received: from MWHPR03MB2813.namprd03.prod.outlook.com ([10.175.135.7]) by MWHPR03MB2813.namprd03.prod.outlook.com ([10.175.135.7]) with mapi id 15.01.0659.025; Sun, 16 Oct 2016 01:00:33 +0000 From: Shawn Steele To: "ima@ietf.org" Thread-Topic: [IETF] Content Issues [ Thread-Index: AdInSGoNlaqwg5dxQCSUup0Iyls68g== Date: Sun, 16 Oct 2016 01:00:33 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Shawn.Steele@microsoft.com; x-originating-ip: [50.35.76.48] x-ms-office365-filtering-correlation-id: a22cb50d-6f41-4417-1e5f-08d3f55fd556 x-microsoft-exchange-diagnostics: 1; MWHPR03MB2813; 7:Zm8QycjmHAR/wj6wsCPnxeD9dUQZyZnlm5sbWaF8Ip8mMOclsA2WWy7RSxoXbrLVi2/cc0NcFsf6MSms9qxaEPOHhfusi5J02HJIhbnQzad0vsVrMd8aZiT9yUepojJORKsCEwxihCc6QuMr9H9JH0VbObGoC5eiaM2cb6zPphdLsW+zzCthrhHMPXf/jBiyhFb/a+uZUM+C5qF/raeri4vHhwcAXmnUXqwGzg42Ml3JP897nNU9IXoIuMgfe2jHKYz9LYxPu4E8b3Ue+Cc15G7N9IL6/Va/zDsMK+RKk4SqgMfk7407HMVWkApRwqPsOGT1+K2ti40q2LkxD07iYYAXhWnuTvV5fzLAvhD5MF0hs93t0Ogy3Mfvse0Pnb81 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:MWHPR03MB2813; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:MWHPR03MB2813; BCL:0; PCL:0; RULEID:; SRVR:MWHPR03MB2813; x-forefront-prvs: 00979FCB3A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(189002)(97736004)(19580405001)(5640700001)(6916009)(305945005)(7846002)(2501003)(74316002)(11100500001)(2906002)(68736007)(33656002)(10290500002)(105586002)(7736002)(76576001)(7696004)(8990500004)(99286002)(107886002)(122556002)(2351001)(8936002)(54356999)(50986999)(586003)(101416001)(189998001)(106356001)(450100001)(77096005)(92566002)(5005710100001)(10400500002)(66066001)(3280700002)(81156014)(81166006)(5002640100001)(3660700001)(9686002)(110136003)(87936001)(2900100001)(102836003)(5660300001)(10090500001)(1730700003)(6116002)(8676002)(3846002)(86362001)(86612001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR03MB2813; H:MWHPR03MB2813.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Oct 2016 01:00:33.5507 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR03MB2813 Archived-At: Subject: Re: [EAI] [IETF] Content Issues [ X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2016 01:00:36 -0000 > Seriously, at least in the near term, I'd oppose letting anyone post to a= n IETF list from a non-ASCII address. This has been discussed before in ot= her contexts, but it is important that we, as a standards body, be able to = identify who is posting to our lists and trying to influence outcomes.=20 I'm confused because I don't see how EAI addresses would be less accountabl= e than ASCII addresses. Sure, they might be less readable, but surely peop= le could have JohnDoe@SpecialServer.whatever and we'd have no clue who they= "really" were. I'd vote for "eat our own dogfood" -Shawn From nobody Sun Oct 16 03:26:59 2016 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84D6C12969C for ; Sun, 16 Oct 2016 03:26:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.099 X-Spam-Level: X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PDcjylsVy5BF for ; Sun, 16 Oct 2016 03:26:56 -0700 (PDT) Received: from postoffice.net.ua (postoffice.net.ua [62.149.8.98]) by ietfa.amsl.com (Postfix) with ESMTP id 20AE2129411 for ; Sun, 16 Oct 2016 03:26:55 -0700 (PDT) Received: from [46.164.143.170] (account yvk@ua-nic.net HELO [192.168.1.121]) by postoffice.net.ua (DigitalGate Pro SMTP 5.2c3) with ESMTPSA id 427709505; Sun, 16 Oct 2016 13:26:51 +0300 Date: Sun, 16 Oct 2016 13:26:53 +0300 From: Yuriy Kargapolov Organization: uanic X-Priority: 3 (Normal) Message-ID: <776420919.20161016132653@uanic.net> To: Shawn Steele , "ima@ietf.org" In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [EAI] [IETF] Content Issues [ X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2016 10:26:58 -0000 >> Seriously, at least in the near term, I'd oppose letting anyone post to an IETF list from a non-ASCII address. This has been discussed before in other contexts, but it is important that we, as a standards body, be able to identify who is posting to our lists and trying to influence outcomes. Anyone? Let's start from Administrators of IDN ccTLD/gTLD (admin-c or/and tech-c by IANA DB). They are "anyone"? > I'm confused because I don't see how EAI addresses would be less > accountable than ASCII addresses. Sure, they might be less > readable, but surely people could have > JohnDoe@SpecialServer.whatever and we'd have no clue who they "really" were. > I'd vote for "eat our own dogfood" > -Shawn Excuse me, from point of view man with English as mother-language you are right on 100% But some other picture will be from man with, for example, Swahili or Russian or Kyrgyz or Bulgarian ... - so much other mother-languages are exist on Earth Maybe I mistake or I didn't correctly understood you > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima -- Best Regards, Yuri mailto:yvk@uanic.net From nobody Sun Oct 16 07:03:34 2016 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA6551294C2 for ; Sun, 16 Oct 2016 07:03:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.534 X-Spam-Level: X-Spam-Status: No, score=-0.534 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X1d6zr7p4OZh for ; Sun, 16 Oct 2016 07:03:31 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7CB4129404 for ; Sun, 16 Oct 2016 07:03:31 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01Q668S1XKZK00QS6D@mauve.mrochek.com> for ima@ietf.org; Sun, 16 Oct 2016 06:58:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mrochek.com; s=mauve; t=1476626308; bh=9IFgXmUxmAN6Lnx7jCifUNaENWsNK6HsOglNF5JDz6s=; h=From:Cc:Date:Subject:In-reply-to:References:To; b=KUXPL2yMh6VEdDzEXzmN8vqfdYOgd7yqZ/e0lYrSGGEfJ/1kge1Ux2jq0RsWD4DyX GDLUAqGS0S2y4EY5k9AQ/0XZsZbBAKde3WmEIeQrMMe+lRdpPQVgWvTVkocVbGk1Z4 afUmqjxoirg/KjLjijItBhTy26tvqDF2v7KgNsfE= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01Q64TB541DS00Q5OH@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Sun, 16 Oct 2016 06:58:25 -0700 (PDT) From: ned+ima@mrochek.com Message-id: <01Q668S03W0W00Q5OH@mauve.mrochek.com> Date: Sun, 16 Oct 2016 06:48:12 -0700 (PDT) In-reply-to: "Your message dated Sun, 16 Oct 2016 01:00:33 +0000" References: To: Shawn Steele Archived-At: Cc: "ima@ietf.org" Subject: Re: [EAI] [IETF] Content Issues [ X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2016 14:03:33 -0000 > > Seriously, at least in the near term, I'd oppose letting anyone post to an > > IETF list from a non-ASCII address. This has been discussed before in other > > contexts, but it is important that we, as a standards body, be able to identify > > who is posting to our lists and trying to influence outcomes. > I'm confused because I don't see how EAI addresses would be less accountable > than ASCII addresses. Sure, they might be less readable, but surely people > could have JohnDoe@SpecialServer.whatever and we'd have no clue who they > "really" were. You're missing the point. If I send to an IETF list from an EAI address, the message I send is going to be an EAI message. Given the way EAI works, that message is only going to reach the (currently small) subset of list participants for whom the path to their eyeballs is EAI-capable at every step along the way. The effect of this is to essentially to create a EAI-capable subset of any discussion. That breaks accontability, as John notes. But perhaps more important is the fact that it also breaks the entire open model. > I'd vote for "eat our own dogfood" Like it or not, that's not possible at this point. Perhaps that will change at some point in the future when the penetration of EAI has increased, but until it does the best we could offer is to allow EAI addresses to receive the list but not post to the list. And I don't think that's of sufficient utility to bother implementing. Ned From nobody Sun Oct 16 08:39:58 2016 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E26512943B for ; Sun, 16 Oct 2016 08:39:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JMpQ9WPl_lcR for ; Sun, 16 Oct 2016 08:39:56 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0093.outbound.protection.outlook.com [104.47.38.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C653A129404 for ; Sun, 16 Oct 2016 08:39:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=5c3muNZU2KdblwIZUgny516x5BPrV+cnA9OkrqX7dDg=; b=O3ttaOPuxXWEQScHpcQiYfGQo/8FSGAOichvHWTF/1ZR4J/zJM2cl6SH2ne88WaM+QnalLPm0Jcvsr5bNokZW8lWf2aVhRLrXGbc9SIEa/ZUW+Kml7lf+vY5zGwFZmuA9RRNAZ+Pns5v31EhzF3bY4a/T2olhHxz47MV4YB7Q48= Received: from MWHPR03MB2813.namprd03.prod.outlook.com (10.175.135.7) by MWHPR03MB2815.namprd03.prod.outlook.com (10.175.135.9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.659.11; Sun, 16 Oct 2016 15:39:54 +0000 Received: from MWHPR03MB2813.namprd03.prod.outlook.com ([10.175.135.7]) by MWHPR03MB2813.namprd03.prod.outlook.com ([10.175.135.7]) with mapi id 15.01.0659.025; Sun, 16 Oct 2016 15:39:54 +0000 From: Shawn Steele To: Ned Freed Thread-Topic: [EAI] [IETF] Content Issues [ Thread-Index: AdInSGoNlaqwg5dxQCSUup0Iyls68gAbauUzAAM7yRA= Date: Sun, 16 Oct 2016 15:39:54 +0000 Message-ID: References: <01Q668S03W0W00Q5OH@mauve.mrochek.com> In-Reply-To: <01Q668S03W0W00Q5OH@mauve.mrochek.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Shawn.Steele@microsoft.com; x-originating-ip: [50.35.76.48] x-ms-office365-filtering-correlation-id: 955fa24b-a187-4347-f8a8-08d3f5daacf8 x-microsoft-exchange-diagnostics: 1; MWHPR03MB2815; 7:S76goke1XLX8k3nJGoGEm8lAUuPY5scCGAb2M9J70wLFtIHlnIIKY1aXjRb4OZo7UqQDI/ds/cLdQ1YCnfjUYopFwNf1YE/mE2+h6tbMGlGs7foCd04ipbJ0PUDUks3r7iIIjx8L1KSjragOKk9Dsl8AjRj2Lv8nI84U3D9Us7F+GqHU1/rQnz41uIbhM+iYzA7O9jzw3N/1CEUidTSaOta1Y4yAT5C9VXWlHpBeDohSXslnohZW0QhqTY5nXeNLKrpzWIw+PAhgy/YPjSmz7ViFAFQG1HE1+ppBxhGLgA6T53uf79g/ym0MytY00uesJkAs2NcvzA2z8r7tzVlcXTjRCp7HJ/7Xdx0nxfLh1C1LZd0wUYlQJ+YVODEeZ/5l x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:MWHPR03MB2815; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:MWHPR03MB2815; BCL:0; PCL:0; RULEID:; SRVR:MWHPR03MB2815; x-forefront-prvs: 00979FCB3A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(13464003)(199003)(189002)(377454003)(3846002)(86612001)(3280700002)(97736004)(8990500004)(5002640100001)(54356999)(76176999)(50986999)(77096005)(10400500002)(5005710100001)(10090500001)(10290500002)(19580405001)(19580395003)(33656002)(76576001)(189998001)(2950100002)(6916009)(11100500001)(105586002)(101416001)(106356001)(122556002)(8936002)(74316002)(66066001)(305945005)(7846002)(7736002)(68736007)(2906002)(99286002)(87936001)(81166006)(7696004)(110136003)(86362001)(2900100001)(92566002)(586003)(81156014)(8676002)(4326007)(9686002)(6116002)(102836003)(5660300001)(3660700001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR03MB2815; H:MWHPR03MB2813.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Oct 2016 15:39:54.0863 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR03MB2815 Archived-At: Cc: "ima@ietf.org" Subject: Re: [EAI] [IETF] Content Issues [ X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2016 15:39:57 -0000 I suppose it might depend on how it is configured? I suppose the on-behalf= -of or whatever could be tricky, but it is already munging the message. So= maybe it could just ignore the sender info? Certainly there isn't anything blocking the digest version? -----Original Message----- From: Ned Freed [mailto:ned.freed@mrochek.com]=20 Sent: Sunday, October 16, 2016 6:48 AM To: Shawn Steele Cc: ima@ietf.org Subject: Re: [EAI] [IETF] Content Issues [ > > Seriously, at least in the near term, I'd oppose letting anyone post=20 > > to an IETF list from a non-ASCII address. This has been discussed=20 > > before in other contexts, but it is important that we, as a=20 > > standards body, be able to identify who is posting to our lists and try= ing to influence outcomes. > I'm confused because I don't see how EAI addresses would be less=20 > accountable than ASCII addresses. Sure, they might be less readable,=20 > but surely people could have JohnDoe@SpecialServer.whatever and we'd=20 > have no clue who they "really" were. You're missing the point. If I send to an IETF list from an EAI address, th= e message I send is going to be an EAI message. Given the way EAI works, th= at message is only going to reach the (currently small) subset of list part= icipants for whom the path to their eyeballs is EAI-capable at every step a= long the way. The effect of this is to essentially to create a EAI-capable subset of any = discussion. That breaks accontability, as John notes. But perhaps more impo= rtant is the fact that it also breaks the entire open model. > I'd vote for "eat our own dogfood" Like it or not, that's not possible at this point. Perhaps that will change= at some point in the future when the penetration of EAI has increased, but= until it does the best we could offer is to allow EAI addresses to receive= the list but not post to the list. And I don't think that's of sufficient = utility to bother implementing. Ned From nobody Sun Oct 16 08:42:32 2016 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3B1D12945E for ; Sun, 16 Oct 2016 08:42:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5LWsjsMd2f5G for ; Sun, 16 Oct 2016 08:41:32 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0128.outbound.protection.outlook.com [104.47.41.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2936129437 for ; Sun, 16 Oct 2016 08:41:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ui1iRr/I301y0kHSsK9T2kwrsQjHoVr1N0M2ROOGfew=; b=oM4LXuWhBHHzz/+7UtbJMXVGd6MxX/y7aNxKPw/dxgBXIyNc2XspVbiLGuB+3Dy1v6zjqwpGctWaytglrL+5kBBUFjIsD4wvt3LNWtYSJStF7nJtbijPlNbOuSu9SfOB8XEGC2GKuv7CGpACXk2JUdKDe7ZIO3WSqjNQDePQl6E= Received: from MWHPR03MB2813.namprd03.prod.outlook.com (10.175.135.7) by MWHPR03MB2815.namprd03.prod.outlook.com (10.175.135.9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.659.11; Sun, 16 Oct 2016 15:41:30 +0000 Received: from MWHPR03MB2813.namprd03.prod.outlook.com ([10.175.135.7]) by MWHPR03MB2813.namprd03.prod.outlook.com ([10.175.135.7]) with mapi id 15.01.0659.025; Sun, 16 Oct 2016 15:41:30 +0000 From: Shawn Steele To: Yuriy Kargapolov , "ima@ietf.org" Thread-Topic: [EAI] [IETF] Content Issues [ Thread-Index: AdInSGoNlaqwg5dxQCSUup0Iyls68gAT2XuAAArxwUA= Date: Sun, 16 Oct 2016 15:41:30 +0000 Message-ID: References: <776420919.20161016132653@uanic.net> In-Reply-To: <776420919.20161016132653@uanic.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Shawn.Steele@microsoft.com; x-originating-ip: [50.35.76.48] x-ms-office365-filtering-correlation-id: 2e85c046-a7a0-4e47-102e-08d3f5dae663 x-microsoft-exchange-diagnostics: 1; MWHPR03MB2815; 7:lx5U7u3LSNFKdxvx+V8WveAP8jZukyrytYm6ERZ6o03vCtwmHTOA+PZqhv0VPfsKnjswfGc08EeO7uyQyBx4fHiKYVOp4C9rHLWhfi8f/jvKaH9Pxe7MAQfDnJ6pbxmWln1ki3rlUkaQo1tkb0vDCM+s1VNPfJI7lhuuX9Ae9StAf/BE3ngJW9qta4rm1WJvEf/m31bWcfAEqTawrncF5NAjdnBuexP7pPx5zuP3EPAfgTrm/WV+MmTIXdAgqzRJLFu6tflcYW9JFnC1+ddnm5G51LWZkHFwbKbiBAfAg+aBPrr7K0Jf1zm1OTi1RRg7T941Z1tFO2dmwpjaRxP1wlOaRVkL/tVt/s1HMd0heYUlGqioYG9pXaB2hxs7XcVZ x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:MWHPR03MB2815; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:MWHPR03MB2815; BCL:0; PCL:0; RULEID:; SRVR:MWHPR03MB2815; x-forefront-prvs: 00979FCB3A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(189002)(3846002)(86612001)(107886002)(3280700002)(97736004)(8990500004)(5002640100001)(5001770100001)(54356999)(76176999)(50986999)(77096005)(10400500002)(5005710100001)(10090500001)(10290500002)(33656002)(76576001)(189998001)(2950100002)(11100500001)(105586002)(101416001)(106356001)(122556002)(8936002)(74316002)(66066001)(305945005)(7846002)(7736002)(68736007)(2906002)(99286002)(87936001)(81166006)(7696004)(2501003)(86362001)(2900100001)(92566002)(586003)(81156014)(8676002)(9686002)(6116002)(102836003)(5660300001)(3660700001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR03MB2815; H:MWHPR03MB2813.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Oct 2016 15:41:30.5568 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR03MB2815 Archived-At: Subject: Re: [EAI] [IETF] Content Issues [ X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2016 15:42:02 -0000 > Excuse me, from point of view man with English as mother-language you ar= e right on 100% But some other picture will be from man with, for example,= Swahili or Russian or Kyrgyz or Bulgarian ... - so much other mother-langu= ages are exist on Earth Maybe I mistake or I didn't correctly understood yo= u People could already send content in non-English languages if they desired.= So the problem is "only" the address? From nobody Sun Oct 16 09:56:05 2016 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1BDF128E18 for ; Sun, 16 Oct 2016 09:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZtOtGKL_yu6q for ; Sun, 16 Oct 2016 09:56:01 -0700 (PDT) Received: from bsa3.jck.com (static-65-175-133-137.cpe.metrocast.net [65.175.133.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEACE126CD8 for ; Sun, 16 Oct 2016 09:56:00 -0700 (PDT) Received: from hp5.int.jck.com ([198.252.137.153] helo=JcK-HP5.jck.com) by bsa3.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1bvoj2-000Ivu-Em; Sun, 16 Oct 2016 12:55:52 -0400 Date: Sun, 16 Oct 2016 12:55:47 -0400 From: John C Klensin To: ned+ima@mrochek.com, Shawn Steele Message-ID: <7A96FE61E454C7448DE804AE@JcK-HP5.jck.com> In-Reply-To: <01Q668S03W0W00Q5OH@mauve.mrochek.com> References: <01Q668S03W0W00Q5OH@mauve.mrochek.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Archived-At: Cc: ima@ietf.org Subject: Re: [EAI] [IETF] Content Issues [ X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2016 16:56:02 -0000 --On Sunday, October 16, 2016 6:48 AM -0700 ned+ima@mrochek.com wrote: >... > You're missing the point. If I send to an IETF list from an > EAI address, the message I send is going to be an EAI message. > Given the way EAI works, that message is only going to reach > the (currently small) subset of list participants for whom the > path to their eyeballs is EAI-capable at every step along the > way. > > The effect of this is to essentially to create a EAI-capable > subset of any discussion. That breaks accontability, as John > notes. But perhaps more important is the fact that it also > breaks the entire open model. > >> I'd vote for "eat our own dogfood" > > Like it or not, that's not possible at this point. Perhaps > that will change at some point in the future when the > penetration of EAI has increased, but until it does the best > we could offer is to allow EAI addresses to receive the list > but not post to the list. And I don't think that's of > sufficient utility to bother implementing. > > Ned Ned, Yes, exactly. Even for the "receive but don't post" case, it is worth remembering that just including a cc to a non-ASCII address on a message, even if the sender and list addresses are all-ASCII, or having non-ASCII in the headers when all addresses are in ASCII, is sufficient to prevent many members of the community from receiving the message. I haven't thought through the implications of IMAP-accessible archives of messages that require SMTPUTF8 capabilities, but I don't think that would be pleasant either. FWIW, in the IETF context, those who are concerned about not being able to use non-ASCII addresses because the local parts cannot properly represent their personal names should probably be pushing much harder on more substantive issues like why the IETF does not allow list postings in their preferred languages and provide (and insist on) real-time parallel translation at meetings for all of the languages whose users might be present. Those are important, substantive, issues and not resolving them prevents the community to be as diverse and open as it might otherwise be. Mailbox names are just identifiers. I'd probably feel differently if we had no provision for what were historically often called "personal name phrases". But those arrangements have existed ever since we discovered that being able to associate personal names with serially-assigned account identifiers was useful (e.g., knowing me as "M3418" was never helpful and was hard on transparency). The required functionality goes back to at least RFC 822 (and IIR earlier) and has been possible with encoded words (which are widely supported) since MIME was introduced 24 years ago. john From nobody Sun Oct 16 10:24:32 2016 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFBE112943B for ; Sun, 16 Oct 2016 10:24:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0dDtSAwpqwmg for ; Sun, 16 Oct 2016 10:24:29 -0700 (PDT) Received: from bsa3.jck.com (static-65-175-133-137.cpe.metrocast.net [65.175.133.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DCC2126D73 for ; Sun, 16 Oct 2016 10:24:29 -0700 (PDT) Received: from hp5.int.jck.com ([198.252.137.153] helo=JcK-HP5.jck.com) by bsa3.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1bvpAi-000J2q-JH; Sun, 16 Oct 2016 13:24:28 -0400 Date: Sun, 16 Oct 2016 13:24:23 -0400 From: John C Klensin To: Shawn Steele Message-ID: <532EC6872314DFB0CC2B5F46@JcK-HP5.jck.com> In-Reply-To: References: <01Q668S03W0W00Q5OH@mauve.mrochek.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Archived-At: Cc: ima@ietf.org Subject: Re: [EAI] [IETF] Content Issues [ X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2016 17:24:31 -0000 --On Sunday, October 16, 2016 3:39 PM +0000 Shawn Steele wrote: > I suppose it might depend on how it is configured? I suppose > the on-behalf-of or whatever could be tricky, but it is > already munging the message. So maybe it could just ignore > the sender info? > > Certainly there isn't anything blocking the digest version? As long as the digest version does not contain non-ASCII headers. Remembering that the EAI specs encourage getting rid of encoded words in favor of Unicode in UTF-8 in the headers, the digesting mechanism would have to be able to translate non-ASCII header information back. That is certainly feasible but I'm not sure it ought to be our highest priority. The tools needed to do could be part of another issue that affects broad deployment of SMTPUTF8 address and header material. Ned can check me on this, but I think our assumption when MIME was being developed was that, when a message was being forwarded and had non-trivial structure or a charset parameter different from that of the person/MUA doing the forwarding, the norm, perhaps the norm for most forwarded messages, would be encapsulation of the original message. As things have worked out, sometimes we do that and sometime we just include the forwarded message inline (I can't guess which approach is in the majority). If I have an fully-SMTPUTF8-capable environment, receive a message that requires non-ASCII header and address handling, and want to forward that message to a colleagues whose systems are less capable, I'm going to have to either fully encapsulate the original message and any relevant header material or I have a downgrading problem. That problem is closely related to the issues discussed in RFC 6857 and 6858, but the POP and IMAP cases can assume some level of cooperation and choice about client-server pairs and configuration. The forwarding case generally cannot. Harish and Nalini, many of these issues were discussed at length (on the list, in meetings (IETF and the workshops), and in the halls) during and after the development of the EAI specs. Except for some asides in RFC 6530 and elsewhere, the material has not been written down. As I think about this discussion, I think a great first step in what you are trying to accomplish would be to try to simply draw this material together into an Informational document that discusses barriers and impediments to deployment. It seems to me that your current draft goes several steps beyond that and toward best practices. In that context, some of my complaints and quibbling about technical details are premature and a result of there not being an adequate foundation. best, john From nobody Sun Oct 16 11:04:05 2016 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 040141294B4 for ; Sun, 16 Oct 2016 11:04:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xIxgOccOVshe for ; Sun, 16 Oct 2016 11:04:02 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0119.outbound.protection.outlook.com [104.47.34.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59B9B1294B9 for ; Sun, 16 Oct 2016 11:04:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=pUoS6UQVIIf+ZGCpq86r/5/k81LCX4Ykb2VRPrjgjV0=; b=E+p4W48i5iXTTsB2xxP/GcmMJTEMjxCJZnStunb+zt/9TDRfNavRbwLqdvZabIWCzLH2QMa+99oW1b8Y9i413gH9nrEur9qglSWbc7pbSO8+HC2Ew2Nm2zBMzKHEjngxrpzZcDY8m536wnb6U4SVUnHQntRSKp67P94nzffaPiU= Received: from MWHPR03MB2813.namprd03.prod.outlook.com (10.175.135.7) by MWHPR03MB2813.namprd03.prod.outlook.com (10.175.135.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.659.11; Sun, 16 Oct 2016 18:04:01 +0000 Received: from MWHPR03MB2813.namprd03.prod.outlook.com ([10.175.135.7]) by MWHPR03MB2813.namprd03.prod.outlook.com ([10.175.135.7]) with mapi id 15.01.0659.025; Sun, 16 Oct 2016 18:04:01 +0000 From: Shawn Steele To: John C Klensin Thread-Topic: [EAI] [IETF] Content Issues [ Thread-Index: AdInSGoNlaqwg5dxQCSUup0Iyls68gAbauUzAAM7yRAAA8eKgAABUzlg Date: Sun, 16 Oct 2016 18:04:01 +0000 Message-ID: References: <01Q668S03W0W00Q5OH@mauve.mrochek.com> <532EC6872314DFB0CC2B5F46@JcK-HP5.jck.com> In-Reply-To: <532EC6872314DFB0CC2B5F46@JcK-HP5.jck.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Shawn.Steele@microsoft.com; x-originating-ip: [50.35.76.48] x-ms-office365-filtering-correlation-id: ba17e935-8f8d-465e-4061-08d3f5eecf09 x-microsoft-exchange-diagnostics: 1; MWHPR03MB2813; 7:97PYy9AZrTYEeCFYPsD0ojN6jFVpoG8sRXmlHCDzTjXs3zSSH8V91eiuMrR9+MQFpM/jCRS7hT/B3WldaaTcTwmYMXW1XS5bF64FfLHBEsE8PgYZ/2Gi8/vkPRrt2Ld8QNavUR8p9FM/KXUgT7IiQJUS54rgBvfFsogqz/VNA6vWKR80EIiqqsdCuIsZ7Zmn48iPFi4/84pB5dHj+3flut7M/ccQOyNoZF0xfAyHfPtDroT2nyo7eifrXvBXcOPoGKCrQfp9xanNm2VB4/+ImCVM618ZtIyuMf3Uh3tZX6qkCreYZUmbOf2+iMsmhlFFmv+xtkGGS/hX+FjVqJLKCw3Yh//SaQ21cHB+GYoE7YXw8PsDzUZwhxGEu4UfISpb x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:MWHPR03MB2813; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:MWHPR03MB2813; BCL:0; PCL:0; RULEID:; SRVR:MWHPR03MB2813; x-forefront-prvs: 00979FCB3A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(7916002)(199003)(189002)(97736004)(305945005)(7846002)(74316002)(2950100002)(6916009)(2906002)(11100500001)(33656002)(68736007)(10290500002)(105586002)(7736002)(8990500004)(76576001)(99286002)(122556002)(76176999)(586003)(54356999)(8936002)(50986999)(101416001)(189998001)(77096005)(5005710100001)(92566002)(4326007)(10400500002)(66066001)(3280700002)(81156014)(5002640100001)(81166006)(3660700001)(7696004)(110136003)(9686002)(87936001)(106356001)(2900100001)(5660300001)(558084003)(10090500001)(86362001)(8676002)(6116002)(102836003)(3846002)(93886004)(86612001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR03MB2813; H:MWHPR03MB2813.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Oct 2016 18:04:01.2182 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR03MB2813 Archived-At: Cc: "ima@ietf.org" Subject: Re: [EAI] [IETF] Content Issues [ X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2016 18:04:04 -0000 > It seems to me that your current draft goes several steps beyond that and= toward best practices.=20 You seem to have segued from my reply to the draft being discussed, so "you= r" appears to have changed meaning from the beginning to the end of the par= agraph ;-) -Shawn From nobody Sun Oct 16 11:38:33 2016 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62FFD12947C for ; Sun, 16 Oct 2016 11:38:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iViqNgqeRoLS for ; Sun, 16 Oct 2016 11:38:31 -0700 (PDT) Received: from bsa3.jck.com (static-65-175-133-137.cpe.metrocast.net [65.175.133.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFB65129473 for ; Sun, 16 Oct 2016 11:38:30 -0700 (PDT) Received: from hp5.int.jck.com ([198.252.137.153] helo=JcK-HP5.jck.com) by bsa3.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1bvqKF-000JJy-Er; Sun, 16 Oct 2016 14:38:23 -0400 Date: Sun, 16 Oct 2016 14:38:18 -0400 From: John C Klensin To: Shawn Steele Message-ID: In-Reply-To: References: <01Q668S03W0W00Q5OH@mauve.mrochek.com> <532EC6872314DFB0CC2B5F46@JcK-HP5.jck.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Archived-At: Cc: ima@ietf.org Subject: Re: [EAI] [IETF] Content Issues [ X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2016 18:38:32 -0000 --On Sunday, October 16, 2016 6:04 PM +0000 Shawn Steele wrote: >> It seems to me that your current draft goes several steps >> beyond that and toward best practices. > > You seem to have segued from my reply to the draft being > discussed, so "your" appears to have changed meaning from the > beginning to the end of the paragraph ;-) Yes, it probably did. "your" (actually both times) in the paragraph you quote above was intended primarily for Harish and Nalini as I indicated at the beginning rather than you (Shawn) or anyone else specific. Sorry for the confusion. Of course, I assume they would be happy to have help from you, Ned, Yuriy, or anyone else on this list. best, john From nobody Sun Oct 16 11:38:49 2016 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56AFD1294D6 for ; Sun, 16 Oct 2016 11:38:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.433 X-Spam-Level: X-Spam-Status: No, score=-2.433 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UV73ZFFj_z4j for ; Sun, 16 Oct 2016 11:38:47 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4687C129467 for ; Sun, 16 Oct 2016 11:38:47 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01Q66IEAOQ7K00AOKI@mauve.mrochek.com> for ima@ietf.org; Sun, 16 Oct 2016 11:33:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mrochek.com; s=mauve; t=1476642822; bh=tQAJhz8W912jOStuQ5xOf9DZpBpOFyz9Rxo+IAIxpc0=; h=From:Cc:Date:Subject:In-reply-to:References:To; b=WRW8h76Nl4UOX4WhGItV8fuoqeBES+DsC3fvZdtSHQkqgiykjR4Oabt/Z/BKvGRL6 3Q9EZE8lFFHE5wDvguwpS3i3lfRYUfkZ0S7sLHcX3FpZ3cxTrvkluDTLwWpJMmw8hJ Htntdr9hpG20qugc+SZYuzbUGZd1et+8DakLqKko= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01Q64TB541DS00Q5OH@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Sun, 16 Oct 2016 11:33:39 -0700 (PDT) From: ned+ima@mrochek.com Message-id: <01Q66IE8JRBW00Q5OH@mauve.mrochek.com> Date: Sun, 16 Oct 2016 11:28:18 -0700 (PDT) In-reply-to: "Your message dated Sun, 16 Oct 2016 15:39:54 +0000" References: <01Q668S03W0W00Q5OH@mauve.mrochek.com> To: Shawn Steele Archived-At: Cc: Ned Freed , "ima@ietf.org" Subject: Re: [EAI] [IETF] Content Issues [ X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2016 18:38:48 -0000 > I suppose it might depend on how it is configured? I suppose the > on-behalf-of or whatever could be tricky, but it is already munging the > message. So maybe it could just ignore the sender info? Which makes it impossible to properly identify, or contact, the person who sent the message. And accountability goes out the window. > Certainly there isn't anything blocking the digest version? First, most active partcipants don't use digests, so even if this worked it creates another subsetting, which is unacceptable. Second, it doesn't actually work. To the extent digests recreate the semantics of the original set of messages, they recreate the problems the original messages had. Explode the digest and you're back where you started. Ned From nobody Sun Oct 16 13:01:36 2016 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E0451279EB for ; Sun, 16 Oct 2016 13:01:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SfImVyaCcp-p for ; Sun, 16 Oct 2016 13:01:32 -0700 (PDT) Received: from nm20-vm0.bullet.mail.ne1.yahoo.com (nm20-vm0.bullet.mail.ne1.yahoo.com [98.138.91.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92C281293EB for ; Sun, 16 Oct 2016 13:01:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1476648092; bh=iC3VsSzihoDP8n9tuoAKB/X67V2TPiXYZwdPJbXprAc=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=XX7Za8DdY13zW2W/Fh5Kg5dhV1lNgNRACr3eB2KEXEyJcDi9Ze2AUS1yk34NPYnMz96yzMpZUHANec7f8cjzg6oQI6bVf/+7kagCw/pyCFoE3CBBmyyudg66Pealyde6Sw4axp7D3JpGzGv9IjKzPc1GNT7Tizx1fStx/L+7TlrYO6L74hGb+RUfdnzM6VtRhUgC4Q2tbXJDmZ2Sr804M063j6Llgd17vRI5dmVjj+GFLqCj6Ld81Q0/MX0FdOKjMpFQA0x8fkVJyMO41eRau8j75Y7wDhx9KgJ06yFatKFPBWXlklnFXbRL3/pTZVqlQMRCvh1/Qy9Yd/FV0NjBPg== Received: from [98.138.100.103] by nm20.bullet.mail.ne1.yahoo.com with NNFMP; 16 Oct 2016 20:01:32 -0000 Received: from [98.138.226.160] by tm102.bullet.mail.ne1.yahoo.com with NNFMP; 16 Oct 2016 20:01:31 -0000 Received: from [127.0.0.1] by omp1061.mail.ne1.yahoo.com with NNFMP; 16 Oct 2016 20:01:31 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 961017.33381.bm@omp1061.mail.ne1.yahoo.com X-YMail-OSG: ZQhHMp0VM1nhUorAnfBdqX6YjwJgVkozHYg.Nc67LKcjvQJZonLmg7vpK6lh9.H lcByIv4unxD6TXfx6SGTkjsci7JjlIewntwA7Fx1XL5_T6QuH3nHqx1A0M3ZY9D0VyJ1X2VH8l3h v2nOfmSnRaDTN75huUWReGj2dM_RYHMmsnFqtxNrcQj5Xux3qt21RwWoswhzePyBzTUKZHlh29u2 mZBUZyKuxkW4Tywov9QAZStK76AH8POa9azNmAsMsMYFWZxfcMzmvssx2PbVyHkOjY3BcDiBGIam O3.AnyQeBzrn4lsKNRL0H9nD_52bH5yuPDcVCgx1TflrRud3i7uli1kUWiPT2UUQaaCMJluPwSQb dxsaSTk3L0n8YO6veOlyeKuA7FNzQcFnrBE3yHnzbq.tL.Lb7DGCunz4Li_AoTtankOxMsDtNDwL T6D3yzlIYvqx0Oie2P01u8qpY8wflpQv7kqhMXYWVeaIFRgCCCx_DiPXZJ4QTVz2IMsBGRPX1fYt e_EEssrgXFrvsHmqM55wRfJXZE4moO0aulbt.RQkJJ6JULWLofRs- Received: from jws200081.mail.ne1.yahoo.com by sendmailws158.mail.ne1.yahoo.com; Sun, 16 Oct 2016 20:01:31 +0000; 1476648091.578 Date: Sun, 16 Oct 2016 20:01:30 +0000 (UTC) From: To: John C Klensin , Shawn Steele Message-ID: <783239201.731221.1476648090891@mail.yahoo.com> In-Reply-To: <532EC6872314DFB0CC2B5F46@JcK-HP5.jck.com> References: <01Q668S03W0W00Q5OH@mauve.mrochek.com> <532EC6872314DFB0CC2B5F46@JcK-HP5.jck.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Harish Chowdhary , "ima@ietf.org" Subject: [EAI] [IETF] Barriers to Deployment [ was: Content Issues] X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: nalini.elkins@insidethestack.com List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2016 20:01:34 -0000 John, >Harish and Nalini, many of these issues were discussed at length >(on the list, in meetings (IETF and the workshops), and in the >halls) during and after the development of the EAI specs. >Except for some asides in RFC 6530 and elsewhere, the material >has not been written down. As I think about this discussion, I >think a great first step in what you are trying to accomplish >would be to try to simply draw this material together into an >Informational document that discusses barriers and impediments >to deployment. It seems to me that your current draft goes >several steps beyond that and toward best practices. In that >context, some of my complaints and quibbling about technical >details are premature and a result of there not being an >adequate foundation. I like the idea of a "Barriers to Deployment" document very much. I have also been following the discussion of the subscription to email lists. I think that joining such lists is one of the important uses of email addresses. I was just talking this morning to one of the not-very-computer-literate older ladies in the neighborhood and she was telling me about how useful she found the neighborhood email group to be. So, I can see that this is something many people (not just IETFers!) probably find useful. Harish & I will put our heads together and put together some bullet points on the potential "Barriers to Deployment" draft and then come back to the list for comments on major issues to be covered. Meanwhile, Harish is trying to get in touch with Don at the UASG group. I will also ask some of the other people from Latin America / Africa who may be interested in this topic to join the IMA email list. We want to schedule a Bar BoF to discuss these topics in Seoul. I am thinking Thursday morning breakfast meeting. Maybe people can respond to me / Harish privately to let us know if there are conflicts. The title of the Bar BoF will be "Deployment Issues for IDN / IEA". This way, we can start working on at least consolidating the problems. Then, work quietly to resolve them. Thoughts? Thanks, Nalini Elkins (for Nalini & Harish) Inside Products, Inc. www.insidethestack.com (831) 659-8360 ________________________________ From: John C Klensin To: Shawn Steele Cc: ima@ietf.org Sent: Sunday, October 16, 2016 10:24 AM Subject: Re: [EAI] [IETF] Content Issues [ --On Sunday, October 16, 2016 3:39 PM +0000 Shawn Steele wrote: > I suppose it might depend on how it is configured? I suppose > the on-behalf-of or whatever could be tricky, but it is > already munging the message. So maybe it could just ignore > the sender info? > > Certainly there isn't anything blocking the digest version? As long as the digest version does not contain non-ASCII headers. Remembering that the EAI specs encourage getting rid of encoded words in favor of Unicode in UTF-8 in the headers, the digesting mechanism would have to be able to translate non-ASCII header information back. That is certainly feasible but I'm not sure it ought to be our highest priority. The tools needed to do could be part of another issue that affects broad deployment of SMTPUTF8 address and header material. Ned can check me on this, but I think our assumption when MIME was being developed was that, when a message was being forwarded and had non-trivial structure or a charset parameter different from that of the person/MUA doing the forwarding, the norm, perhaps the norm for most forwarded messages, would be encapsulation of the original message. As things have worked out, sometimes we do that and sometime we just include the forwarded message inline (I can't guess which approach is in the majority). If I have an fully-SMTPUTF8-capable environment, receive a message that requires non-ASCII header and address handling, and want to forward that message to a colleagues whose systems are less capable, I'm going to have to either fully encapsulate the original message and any relevant header material or I have a downgrading problem. That problem is closely related to the issues discussed in RFC 6857 and 6858, but the POP and IMAP cases can assume some level of cooperation and choice about client-server pairs and configuration. The forwarding case generally cannot. Harish and Nalini, many of these issues were discussed at length (on the list, in meetings (IETF and the workshops), and in the halls) during and after the development of the EAI specs. Except for some asides in RFC 6530 and elsewhere, the material has not been written down. As I think about this discussion, I think a great first step in what you are trying to accomplish would be to try to simply draw this material together into an Informational document that discusses barriers and impediments to deployment. It seems to me that your current draft goes several steps beyond that and toward best practices. In that context, some of my complaints and quibbling about technical details are premature and a result of there not being an adequate foundation. best, john _______________________________________________ IMA mailing list IMA@ietf.org https://www.ietf.org/mailman/listinfo/ima From nobody Sun Oct 16 15:05:50 2016 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4FB11293EC for ; Sun, 16 Oct 2016 15:05:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.841 X-Spam-Level: X-Spam-Status: No, score=-0.841 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OyYDYDwjBaNo for ; Sun, 16 Oct 2016 15:05:48 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D72CD1293DF for ; Sun, 16 Oct 2016 15:05:47 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01Q66PLZIJOW00O9WR@mauve.mrochek.com> for ima@ietf.org; Sun, 16 Oct 2016 15:00:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mrochek.com; s=mauve; t=1476655244; bh=/fFkmjqwD0iBImdNKWj5CYoReMMt5dlNU+/YE0jmDMw=; h=From:Cc:Date:Subject:In-reply-to:References:To; b=GA6Z4NVUCOanSoGweqmU0tJWA6WuN9LFXBLoSzWV2CDSS4KlPr3jcIQ9hWFRC1cbx A2xGLWe7xdYsMXV3SsOoIhe6YswzxzrbnbVIHwL8hdT5S6kRZJki6kJnoFPYx1y0Yj OPxdtmqMFabq9Su3yDa0V8Rx4khlodHjU/vEAdo0= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01Q64TB541DS00Q5OH@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Sun, 16 Oct 2016 15:00:41 -0700 (PDT) From: ned+ima@mrochek.com Message-id: <01Q66PLXP7X800Q5OH@mauve.mrochek.com> Date: Sun, 16 Oct 2016 11:35:33 -0700 (PDT) In-reply-to: "Your message dated Sun, 16 Oct 2016 15:41:30 +0000" References: <776420919.20161016132653@uanic.net> To: Shawn Steele Archived-At: Cc: "ima@ietf.org" Subject: Re: [EAI] [IETF] Content Issues [ X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2016 22:05:48 -0000 > > Excuse me, from point of view man with English as mother-language you are > > right on 100% But some other picture will be from man with, for example, > > Swahili or Russian or Kyrgyz or Bulgarian ... - so much other mother-languages > > are exist on Earth Maybe I mistake or I didn't correctly understood you > People could already send content in non-English languages if they desired. > So the problem is "only" the address? Someone can post in French or Spanish or even Myaamia or Mingo, but good luck getting people to read it. Which means you can do it but it isn't supported in any meaningful sense. The impediments to actually supporting posting to an IETF list in languages other than technical English are very real, but for the most part non-technical. The IETF could, if it so desired, adopt a multilingual approach similar to that used in some other standards bodies, where a specific set of languages are supported and translation is done on an as-needed basis. Heck, the IETF could even go "full United Nations" and support a huge range of languages - in theory at least. The problem with all this is cost. Even when done really well - and doing this stuff well is extraordinarily difficult - the burden on participants in terms of translation delays, misunderstandings, and so on is very high. So much so that the IETF as we know it would likely cease to exist. And that's ignoring actual cost, which would be huge. And the money to pay for it would have to come from somewhere. The way other organizations do it always includes some element of "pay for play". And that, again, would change the IETF into something unrecognizable. The bottom line is right now the cost of participation in the IETF is being able to read and write technical English to a reasonable degree plus access to basic Internet email service. Replacing that one language with a list is almost certainly going to add some kind of additional cost to the equation. I don't think this is a good tradeoff. Bringing this back to the original issue of being able to use an EAI address on IETF lists, if you want that to work and not break our current model for participation and accountability you're going to have to require that everyone use an EAI-capable account and user agent. Even if you could get IETF participants to do that - and I can assure you that pigs will fly first - think about the added cost of participation that brings. I don't think this is a good tradeoff either. Ned From nobody Sun Oct 16 21:23:09 2016 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FD11129515 for ; Sun, 16 Oct 2016 21:23:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.331 X-Spam-Level: X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5CfkNCEx9ejn for ; Sun, 16 Oct 2016 21:23:06 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 161781293E3 for ; Sun, 16 Oct 2016 21:23:06 -0700 (PDT) Received: from [198.252.137.10] (helo=JcK-HP8200) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1bvzRz-000I1Z-7B; Mon, 17 Oct 2016 00:22:59 -0400 Date: Mon, 17 Oct 2016 00:22:54 -0400 From: John C Klensin To: nalini.elkins@insidethestack.com Message-ID: <7FA831D4B3709857DB95DE56@JcK-HP8200> In-Reply-To: <783239201.731221.1476648090891@mail.yahoo.com> References: <01Q668S03W0W00Q5OH@mauve.mrochek.com> <532EC6872314DFB0CC2B5F46@JcK-HP5.jck.com> <783239201.731221.1476648090891@mail.yahoo.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: Harish Chowdhary , ima@ietf.org Subject: Re: [EAI] [IETF] Barriers to Deployment [ was: Content Issues] X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2016 04:23:07 -0000 --On Sunday, October 16, 2016 20:01 +0000 nalini.elkins@insidethestack.com wrote: >... > I have also been following the discussion of the subscription > to email lists. I think that joining such lists is one of > the important uses of email addresses. I was just talking > this morning to one of the not-very-computer-literate older > ladies in the neighborhood and she was telling me about how > useful she found the neighborhood email group to be. So, I > can see that this is something many people (not just IETFers!) > probably find useful. Note that there are a couple of things that are very different between a neighborhood email group and the IETF list. One is that the same requirements for transparency and accountability typically do not apply, at least in the same way. The other is closely related to what at least some of us have believed all along would be the normal deployment model for SMTPUTF8, by deployment within communities, particularly communities with a small number of shared primary languages, who conclude that they need it. If everyone within a particular community is using non-ASCII addresses, typically addresses based on the same language and script, all of the very hard problems about how to design, e.g., globally-adapted MUAs that are localized to the language and culture of particular communities (not just the right script) essentially go away and having to get everyone to upgrade to make a given list with non-ASCII addresses work disappear or become much more focused. > Harish & I will put our heads together and put together some > bullet points on the potential "Barriers to Deployment" draft > and then come back to the list for comments on major issues to > be covered. > > Meanwhile, Harish is trying to get in touch with Don at the > UASG group. > > I will also ask some of the other people from Latin America / > Africa who may be interested in this topic to join the IMA > email list. Excellent. > We want to schedule a Bar BoF to discuss these topics in > Seoul. I am thinking Thursday morning breakfast meeting. > Maybe people can respond to me / Harish privately to let us > know if there are conflicts. The title of the Bar BoF will > be "Deployment Issues for IDN / IEA". This way, we can start > working on at least consolidating the problems. Then, work > quietly to resolve them. > > Thoughts? Note that some of the people who have been contributing to this discussion rarely attend IETF meetings face to face these days. So think about whether their involvement would be useful enough for you to arrange for remote participation. best, john From nobody Mon Oct 17 02:11:13 2016 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BA101294F0 for ; Mon, 17 Oct 2016 02:11:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uxVHDSCjkwPl for ; Mon, 17 Oct 2016 02:11:09 -0700 (PDT) Received: from JPN01-OS2-obe.outbound.protection.outlook.com (mail-os2jpn01on0125.outbound.protection.outlook.com [104.47.92.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA7911294AA for ; Mon, 17 Oct 2016 02:11:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector1-it-aoyama-ac-jp; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=1gL4ci5mZqCKD+nbR1H4BXhiSZ9u99AqEbTD/AtAbSE=; b=V+TwEs5LH70kAabSMU6jlFTi+HS5ofJ/l4xBOtp69rF3skOflvcM8ozXryz/C+oFMnygMTa2/ZaAj/B2QEq/lP+fFUMVeuaU4nb/IMq/p03FzdZKYYXDe3zKgOZf3+C0CTh8p2uGIcAFDFid1jM0pbfU8AWBWgtk/HhUA+YIx9c= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=duerst@it.aoyama.ac.jp; Received: from [133.2.210.64] (133.2.210.64) by TYXPR0101MB0990.jpnprd01.prod.outlook.com (10.168.45.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.659.11; Mon, 17 Oct 2016 09:11:05 +0000 To: , Shawn Steele References: <01Q668S03W0W00Q5OH@mauve.mrochek.com> From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <7f7ec0f8-2a3a-43e6-ebfe-117be6877a13@it.aoyama.ac.jp> Date: Mon, 17 Oct 2016 18:11:03 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <01Q668S03W0W00Q5OH@mauve.mrochek.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [133.2.210.64] X-ClientProxiedBy: KAWPR01CA0034.jpnprd01.prod.outlook.com (10.165.48.144) To TYXPR0101MB0990.jpnprd01.prod.outlook.com (10.168.45.145) X-MS-Office365-Filtering-Correlation-Id: d1381969-fb1b-4185-ec47-08d3f66d8627 X-Microsoft-Exchange-Diagnostics: 1; TYXPR0101MB0990; 2:dRt3JM9GX4u0/wZoihsTDNfB07b4Dh3wrP/fc8ISuyHmZjWfi58jSOjb/kVaBgSTuTnqoKZ3LjWz+gX12pkmhgZOvVT3Ab7k/B7wXEphXX7fmPLzhgybrjjTS1YpjfduWXrK1WUXyFfOYNhEByRGrjWbabN5+aGrZsgsUl4HL001hgboDiNgWIxVxgPbB8ob4hHg6uVVqTUPAU/iNJDc+w==; 3:u2kLvT93WaFf7uaigwpDQxoYbNC+e7e1gm8I5sRnFGl2/74uACeNCfL7TZ9HIooG6FvsyCWSTGzjtQNEoFGIndeWJCKOctthRbtduVW5nGsEjTK5edwR1v2yyJBje0CvNF7K6cxLNck9qnwD1sPGLw== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:TYXPR0101MB0990; X-Microsoft-Exchange-Diagnostics: 1; TYXPR0101MB0990; 25:smtAunthPzqFkPab/t9u6/FyoODxxfZoPZXb0cOvGhin2BozOoAZoZ90ho1Z1CHaNmospk0sxRnK/0D9H41TOndIvKP8G6vu0h8DDoAarjZcVdNVvUETPKlrEjF6nWOgbzivJsCqoJghAbFaMurUgd9FKUMWAloZaYhlS0U45XyMV7Io6bE53n1CelQy0RZhk/Qu/i1foA3jaFAGXJB/hpqkWBVtrCVS7FETDAjTkC2kQB/0kJNXxq7g0j3+HtEittoZQcWAjlS9dYWMeqaSMv/Mq3vVg0Z9wQdCiaZwL3HvFC2sm+1KxZDENLRk+dUN54xjHwsn9X8eRi0/dh0CTCaf5CYneh8OakvIsTQqyZzPzDHFokk1QI48nrbhMo3CXdjNUzgGGD75cI66rDBqKrlJDrBiLTqAH16Jyjl0Pq9uxi+/aEjloeuqMegDlmXeLwEqXramhmxT5O99yPoX5n4/mJOP4VmWZ+wwk9YPxro12JHw06OGEbVdceWhRohg16ooSRirWXWlf+dt5TkJimZBQtMRykVgeDXKcNCo3mZZ6VD2zPW6/XyFONKGDDeYNyRHA4ZALKPzIMpaQ+u6KLcpcKbDwcRrURN65avQ53u4VmRqZ6HXUHgr4CmTVcvz/n5Q9G/qxrpxTtt7zmygJmzQyDEfx46lc+LC4iCnD/Sjx8oyS6TOb1KaIGO9hFh8NoKDfy/w0llDn1FOdb5OOfflp5D53UZ0b37sXCJVWpvtvlr+pz7Hb7ucC60x6pUy X-Microsoft-Exchange-Diagnostics: 1; TYXPR0101MB0990; 31:uZojiP+3EgkLnATTUYNF4rzaeH2cwb9FSAJx6n/g8DeGf6YsZSOLc0NU7ohN8rWVWQeQULKVa+oVyNnYq1cRWe6/gozRXHfyovd8ZCfwnCH2hsVgBpwXB+hZdonJp9MbPtHbv4r+YlFNstgTE5Tnn13m3xzjZexayiTNtaVWRLvLg1skq7zy5cZklphvGdBWMcbUBZJNWxsuukZmAO5QzTvLxDHRvvthLXHS6WStjoKodgdWmhKwwCXrC6ByfAWG; 4:T0tre+COTQgzNzn72USl/2xAjhLERSlNN15m16Q84FWSmHECJx//Ii7SnUVaqckmtYieTYkg06m104wGx4d58ZY5XiyPcth+FijwW/Q1x6lXbTf7xvxhiEXC3ltQFW+Vp61hUvFZokNE14HIGPuYckjibSXSShpTOXyTLb/2YAjiqEvuwFi02siOgCJen9s7DYimvLhnPtTE3Pw44yYTfD3x4Yi7g7P1wHLZODejk2RevFF1R5mDgQ5Lkw05cw953gAVxltwgthEIllLBvbyCtQShBsSzkWTLW7EAgBB1AZnnnZ0EkipXW7x4rxaE0bSnKQdLoYxncsLIRZCLk8w2quNXX1cIu/NSJIMB+aLN7e3U++7/ymZ+wPk15bXvQE/G4TbIHozG4qv6OG4NVxCMeckAawxHrladbZPjLYpt04= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6043046)(6042046); SRVR:TYXPR0101MB0990; BCL:0; PCL:0; RULEID:; SRVR:TYXPR0101MB0990; X-Forefront-PRVS: 0098BA6C6C X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(7916002)(189002)(199003)(24454002)(74482002)(4326007)(2906002)(64126003)(31696002)(7736002)(7846002)(50986999)(230700001)(76176999)(305945005)(50466002)(23676002)(8666005)(83506001)(2950100002)(5001770100001)(97736004)(101416001)(8676002)(81156014)(81166006)(5660300001)(189998001)(65826007)(19580405001)(42882006)(54356999)(3846002)(86362001)(66066001)(77096005)(33646002)(4001350100001)(65956001)(19580395003)(31686004)(92566002)(42186005)(586003)(68736007)(105586002)(65806001)(1511001)(2561002)(47776003)(106356001)(6116002)(2421001)(3940600001); DIR:OUT; SFP:1102; SCL:1; SRVR:TYXPR0101MB0990; H:[133.2.210.64]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: it.aoyama.ac.jp does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtUWVhQUjAxMDFNQjA5OTA7MjM6Z1lSNnZKaXVCZ2MxVWRqQXN2SS9iR3BS?= =?utf-8?B?NUZGMmlDN29vR1BOaGoxNmZvb2JTNDQ1T3E0Mkp0Y3dsR1BSWGJVZnF1djFj?= =?utf-8?B?K251RWltK3BSckNrdGN6S2hvWVFUT0ZGa0lubHNuU1c4Vi9wNjZKeXVqVG5w?= =?utf-8?B?d3RkYWlJQkxoYjQ0Z2RPNWNENHFYSDhWUUFGb0xzZGswOHg4S0ZpNUZHcGt5?= =?utf-8?B?cFUrNEVmblo1M09hWlFOdlJLU3pBeWNXTnoxT25CalRYVHF5cnJUQTc0QWtU?= =?utf-8?B?bXY2elJCeW1rK2JxMlhldUIvRENZc2NqekdxWDUvNUhadnhOMEczcnRLc2xR?= =?utf-8?B?ZThTMnFPUEVHSXVYakpNMGE5UXY5cXpPd0FaSHJwL0JmZkVEWlFhbmNyR2lY?= =?utf-8?B?NnZGQU5reEE3b0hyZlN3dEtXVWQvc1VlTk1sUHI2aWgyNGZKS1BwYSs4aFov?= =?utf-8?B?RHFRZzN4T0F5clBwdTduc0p1b04rajk0U3hrVEluOW9aaHhzbW8vbzBubTdZ?= =?utf-8?B?eHhrdmZ4OFkrSmxLTTNhWUhEMkNPeDBaeEJYTzZicFBTMFhNaitvVE9qVXI2?= =?utf-8?B?aHJqQ2w1Yk5oc2RRTnU0MGZsN3RDS2Q5SS9VOVFOSFhrV1JVZ1BielVhdkl5?= =?utf-8?B?aTZRNGZyK0RXNksram51RjZXQzQrWkw0MXRBZ3B5K0lySXZKRGdWb0Z5ZUpI?= =?utf-8?B?S1BSaGVrWDFoLzFjT25aRU1ISzVRSXBxcHJLM3NIdlFFZ0NhZk9wUmpTdXdP?= =?utf-8?B?MjRqdUIxL3FQVzRxQ0ltSFZPNEZmVzkzbUVHRkFYdERmK3hzRCtrSkZGalVa?= =?utf-8?B?TndTZ2tQY0l4K3lJaVYvU1lsMDZ2ZTVQZ2tyTnpqRXpyS1F3bEI1T3VXZVdL?= =?utf-8?B?UVFkQU9EWG5Bdkx1UGhvSmhBVTVua1ppQStoMHZvM3B4UitaSkpRU3lkVWhJ?= =?utf-8?B?L3gzU1VTTTNwQ1lmUGMrR1ArVytRSWxZdUpqeTNkazJYWFJldjhhRkNCOUg2?= =?utf-8?B?S2dNMHdMVkR6TDlheTBPaUllZGIwT2VSTU1DaXJwVVpOTzZGa1lSU2R1bzE1?= =?utf-8?B?aGUzd2RBNjZ2Q3pNRXE4ZFhRcEM5SzBPWDlNZGE3M05hYlVpSWVJa0J1Qm9L?= =?utf-8?B?ZTlWWlZ3bHYxbmRtbHZzdlBvL2RQSy9TVXZXR2U4aEZRWXZwZFRCbDliZ3Yr?= =?utf-8?B?RDRLLzJ5WkFwdkpYeTcvNVBlVWZ5NHJXYUo1ZFdIT1o5NEVuK0NlV0Y1Rmt1?= =?utf-8?B?QmRCUmNqb0srZGRvanVva2JJeFdYME15T0J3TjhLc0NwSTREZllrNHZmOXl2?= =?utf-8?B?NVpxMHRHMHpOVzR2VjhCa0V5UzRQcS9XY1Qva0syVng1VERQRDgwTTBZWlNi?= =?utf-8?B?V0Jpb3RjTXZBUGdtbGluWGR5dHJjU1JmbkxkbjVLVzZ1d1pvSDlpODlRVTlu?= =?utf-8?B?aTJCYksycnRaNmJTT09zT1VDR2pkYzhKUUxmc1htVWp3NXZJUkw2cFM3RHlI?= =?utf-8?B?QmQ3WkpHVUFZdW5QbmdNLzhkcFp4YWlWRGdpVUtOWmQvYlM2Z3YrY09STExT?= =?utf-8?B?NjcwNXg5WXRwYUVuQnNSdEZsc1hZbkYzbTFJZFgzYW1ocXJmMzBSWHdLSkJw?= =?utf-8?B?SnlqQzllaStxTzdnQyt5ZTh1Y1BMMUIyUkU4UTVPaE8xV2t5MWdrQzZDOHNx?= =?utf-8?B?KzlQWFd4UXkyODlrejVOOXMrRCtCQWZKaTM2MWt2aytHeXEwMXNFRGhkZG1H?= =?utf-8?B?cUJtZWhKZ2NlTXE0SjJ3SHVNSGJEOGxGTU53TjN4TUYwMUVRZmNNZXRYamgx?= =?utf-8?B?YStqdzhXVzZ2dWw1WEhFbis3OWw4QmFhaDEzT2VPY0o0aTBpNzhxak9xdFZT?= =?utf-8?Q?Fl3WB/KMj2OuXHggKUre10QYtxuLpdZTLu?= X-Microsoft-Exchange-Diagnostics: 1; TYXPR0101MB0990; 6:cS2a5Pt8uig4JXAcZPIlibXHL1gBjs0SyfwsU+gzmiOR4uh9lMqNOSF25iOXgsXBsWe4ZkMfrQUsMpGuHgdjIAcoXFgf+QkNnA1HYcsgIChf+69Zf/rZWCLlbCUiCPUFgZsFNXyd/VYuxh5qGEo7TJEsNhTfL1cdhACgyF2Jf8pwfjTm6vJ+7r0+hvr8/9ilQtviu2+ws4n5oGuNX3oh46WpalKPyKpowl8DlY9+McvektIv+mnN9jw+C27NLMF8KGEyR1HhT5gS6uI1Sy1KXnfITZNPP81ZwQMcKq9KTPJ73PFU/huhvKOykGYgeuyP1OSuUoJjG1KYZ4uPnGzL0w==; 5:Cg1voaguU5tYKImH+AeGUc3wWwOGU78OR78ohm2pY5kOOesxSG5pw1BGUh86XYRxCjHvDA2fTj3F+cwdU2MGwvcvBaCJHsMt3EQQOoi9UISckVhfFNaVccfKnYx9v2NMqGiZAlq7GwZC1yH8lH0jJc/CW63Aic4UHGEw845+gJY=; 24:oMgz6xdqE8BOTqdJyEvOt93GD5MyK/eSO2zZ7U0HhUnN8Ah8+N2o6X3gjjbb6l+PIBMda3PYSi2z1oYn2Tof/i6x7JckcdK7qEFeZQknTh8= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; TYXPR0101MB0990; 7:Krh4IXSqNodY8AhNo38L0ulaMxzby47Y328VmsilWoAxVu8DhepKrICyyK/MLqj0expg7whbJAIyTE7rhxN+dc6WhxUIrrdMdRwFCIKQsI4jbdjXfV8QUxjilUd4MxaGLCA2H3WV3QOheXfrRIt1cwsLF0e3pTgixVY0unJ9xZ8v3Aw9sIh7UxslYP60r6HFmwniFndxVBeqHIWff8Sqn/6rGMu/ssbd3orVETVXPsxkrsW4IR93As8zSXKIzXwsFFOEQ7BMsx6f74ajKhFHZPzLNw5bkqHlRhWrklfcEfcJRCuokr34c1063XifCrmrO6+3+G0ULOGjhy0lfbLJ2GEQktxd1PYxJDoXim3GkXg= X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Oct 2016 09:11:05.0752 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYXPR0101MB0990 Archived-At: Cc: "ima@ietf.org" Subject: Re: [EAI] [IETF] Content Issues [ X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2016 09:11:11 -0000 Hello Ned, On 2016/10/16 22:48, ned+ima@mrochek.com wrote: >>> Seriously, at least in the near term, I'd oppose letting anyone post to an >>> IETF list from a non-ASCII address. This has been discussed before in other >>> contexts, but it is important that we, as a standards body, be able to identify >>> who is posting to our lists and trying to influence outcomes. > >> I'm confused because I don't see how EAI addresses would be less accountable >> than ASCII addresses. Sure, they might be less readable, but surely people >> could have JohnDoe@SpecialServer.whatever and we'd have no clue who they >> "really" were. > > You're missing the point. If I send to an IETF list from an EAI address, the > message I send is going to be an EAI message. Given the way EAI works, that > message is only going to reach the (currently small) subset of list > participants for whom the path to their eyeballs is EAI-capable at every step > along the way. In Shawn's defense, I have to admit that I also read John's email as saying "if somebody had a non-ASCII address, they would be less accountable" independent of the mailing list complications that he mentioned afterwards. I was already going to reply to John about this, but then I saw Shawn's mail. > The effect of this is to essentially to create a EAI-capable subset of any > discussion. That breaks accontability, as John notes. But perhaps more > important is the fact that it also breaks the entire open model. Well, the message would go to the mailing list archive, which should be enough for theoretical accountability and openness. But of course, a mailing list where contributions from some set of participants to some other set of participants regularly disappear in a black hole don't make much sense. > Like it or not, that's not possible at this point. Perhaps that will change at > some point in the future when the penetration of EAI has increased, but until > it does the best we could offer is to allow EAI addresses to receive the list > but not post to the list. And I don't think that's of sufficient utility > to bother implementing. For the moment, I agree. Regards, Martin. From nobody Mon Oct 17 02:17:12 2016 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FA1D1295C6 for ; Mon, 17 Oct 2016 02:17:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-yMXk23UiAm for ; Mon, 17 Oct 2016 02:17:04 -0700 (PDT) Received: from JPN01-TY1-obe.outbound.protection.outlook.com (mail-ty1jpn01on0090.outbound.protection.outlook.com [104.47.93.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 418001295C2 for ; Mon, 17 Oct 2016 02:17:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector1-it-aoyama-ac-jp; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=oB0pV08pqmlcaO0OS+ec5xt4hXudfMmTAnzYrCj5nM0=; b=Vdag1Y/XfFha8OZnWD1G1OETV1Xjryk1g167M5NherRmJVHzXmJBUIq+XXatPQrygc07vHLkHbURhHY3WLj2YU/7c42517hhL/EXRj2yvcokLtlObHgqdY7fb4KDtom5gaQia9xu6R+Pj1ofyVIUi780WhtXIzxsngWwAFUV9QI= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=duerst@it.aoyama.ac.jp; Received: from [133.2.210.64] (133.2.210.64) by TY1PR0101MB0985.jpnprd01.prod.outlook.com (10.167.157.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.16; Mon, 17 Oct 2016 09:17:00 +0000 To: John C Klensin , , Shawn Steele References: <01Q668S03W0W00Q5OH@mauve.mrochek.com> <7A96FE61E454C7448DE804AE@JcK-HP5.jck.com> From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <10c2fe1b-223b-3ab7-c9e2-ed37e4b7abb2@it.aoyama.ac.jp> Date: Mon, 17 Oct 2016 18:16:57 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <7A96FE61E454C7448DE804AE@JcK-HP5.jck.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [133.2.210.64] X-ClientProxiedBy: TY1PR01CA0108.jpnprd01.prod.outlook.com (10.167.154.26) To TY1PR0101MB0985.jpnprd01.prod.outlook.com (10.167.157.148) X-MS-Office365-Filtering-Correlation-Id: 6192943b-2e9e-4e04-dda4-08d3f66e5a20 X-Microsoft-Exchange-Diagnostics: 1; TY1PR0101MB0985; 2:raKrkuJaoJFXJ5sPEnd5YQl85n3KetLfXnimbM7DiqmqAErE28mYysMjYnROVqjuC8rXCyKKaWgShAS+GsjxBwEb9+QnHUJOVBLIBpP0mTqN4981JrPHmBkNi6QIpqs6Skt4vrx3CcDET4999dd6PcIOFIcO3Rlj17tQR14A2eaugH0VknzWWLpobt68Bqk9Cd8f+BNLsWufV+eqwGFLUA==; 3:HxJZ23WiseoF/DO7p5TFVqK3eVdC0FiIiL+Rg4nFs2UufoTTTzBeJmH5SBuneYFDc/prstF3KfIllPiv0f8pjDyvkGZmx+AihlKEKsDes9XRsPapTlTK1WUxWUlxy7+xhc8PaK8gEAeTMPXMRvGXaw==; 25:k7cYiuTBXfOzYXwuZsKHPYwK7meptJuXGMmlR3s4/3DEFY5N3pftgKpw6Q0fmtGHEtj7DITCmFZBzjXQoyaTRA4Sf2IoAe7bUCr4mwKHQHNuzblbRL0Tgc00Lu00lylkxso6VYxeX57UfgbpihpPuUGVcYIuvmO6O8GpuQJ8VIXkw1cVQD44nXkjuch++HE9tGDSbmowFJnxXIoOX6n/bXqI4BvGWQREs/9GWbJu+1YJ476+tRQmpyeVUSBgx7RiISIk9WQRs3eclQzw/PoJ3RYJUUhKA4UegeTWjwgXNnV4C6DEi8IwGSSfus7PATtZ/4PUzAuMvVDR5WrJ7sofAjvLve2KitaQnN7VKJyRQxW6u/4nitFSUVRaciU3IQoMHif1Lzx6MfZNtTSZi0j/Pym6RY5CY2R1Ab3fyHbf9ICuSXHMJ59uoB2PGhRjOi+D X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:TY1PR0101MB0985; X-Microsoft-Exchange-Diagnostics: 1; TY1PR0101MB0985; 31:d8T4WTaxG1aHmODjNX1F+EXd1eOLbbFCedvT3Ce4D6UkiNQpb4ujX+RHq30+B6HpKpRW8LNvU/OQu+pbJ/UBKjMc521N1MWFDI4nYVyVRgaP2Y7ve02qld1FL3QVqeFJEvk03E7qrHGnxPt44tPQoE8JBjQ/Kle5xpoVPDYe77PKDIGAI+qWlezkE3gFFnJDCWjkke0A4U2F+Ip6L5fZ8fsaM4JrmuezZyxKB39ovWsF3InOdGu+WWK7o5fDn1pf; 4:OhqXi/7sWa34zde0YElSSvzre23xud7XkrC6f0xPCmzbOp4BLI5NiFR9uJPQJbpK16q8/UEVTlB3R1Ubuw2GF49a3glFv2kV7zd0DtpeVac5btecQAAvv5PpXI9mRArIayNwSKI0Fln8p1GIYhjcckiLfEK6J5U7HI3eWbS7F0SBRdhdKU40Q/PMmPEsmKCMPtUlKUjP+RwupC7aFUyTOsD17tVyRaESz9IORDlL/doNUbBsD+RZpzBw4nf71ps40r3a+py0cA33MyMTjU/qwLxGidi8yJHy2VvfoM7mA20WWL9p7pzo1jlbFFqfNDQNJdKaSpSWmSF5fvUD8H+1ZGT7aFOfPgXZTsr90PFLoU7Uq1rt69anfcQx8/UpNtkkuK+6XSrj4VVUMOZiukIIzj8hybK4iOBmbw+fxKHKPJQ= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6043046)(6042046); SRVR:TY1PR0101MB0985; BCL:0; PCL:0; RULEID:; SRVR:TY1PR0101MB0985; X-Forefront-PRVS: 0098BA6C6C X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(7916002)(199003)(24454002)(189002)(377454003)(23676002)(189998001)(64126003)(31686004)(106356001)(105586002)(7736002)(230700001)(101416001)(1511001)(42186005)(83506001)(2906002)(19580395003)(47776003)(77096005)(68736007)(97736004)(4001350100001)(5001770100001)(66066001)(65956001)(65806001)(19580405001)(92566002)(6666003)(42882006)(2950100002)(74482002)(65826007)(81156014)(8676002)(81166006)(50466002)(76176999)(5660300001)(31696002)(7846002)(305945005)(86362001)(6116002)(8666005)(3846002)(4326007)(33646002)(50986999)(586003)(2421001)(54356999)(2561002)(3940600001); DIR:OUT; SFP:1102; SCL:1; SRVR:TY1PR0101MB0985; H:[133.2.210.64]; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: it.aoyama.ac.jp does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtUWTFQUjAxMDFNQjA5ODU7MjM6c1Z2WkNVYXc0OXdyY0VrcHIvTTdjWldW?= =?utf-8?B?VE1pNHNBdE9TV3A0SmtNanFYQkRuOHVDQmRNLzNCOWVQMUJXcGhXZTRPRjRS?= =?utf-8?B?UHc1eVVWTUFvVXJPRHNZUHl0bXpjeVhjTVYwdkR3SkNjbE1jVEVkUDlsczM0?= =?utf-8?B?d2hzUWxRMTVaaC9nVDQ3Wk1hTFBaSE93Kyt4OWVlODlicitqeU91WEQ2V1lp?= =?utf-8?B?b1pKYnpaczdXMHpRUEgxNXVpOS9SczYxWS93QmtlRFpqMTNoNFpIQTYvZmdq?= =?utf-8?B?bUFQcE5PU3dFeU0yV2tiVEVYN042bFVDNmUwQzNGMVBWTXdEeGZMdSsrbmdR?= =?utf-8?B?RmRub1V1SWRuUXdiREtNVFVMY0l2QzJHcXg1bk9lMXZRbXc1eEZPcWtUSUlQ?= =?utf-8?B?cG5jY20xWmZrZ3FseDlaRllvNXBhYmlZcUJqWXBnZmp6VUxtcEJtZEEyemhI?= =?utf-8?B?TmFTV2FsR1JXdzBWbnZyM1Z5Qld2MkpNUTN3ckhWdlRZbkZCZ1BaSmxWZWVW?= =?utf-8?B?Vks1ZEFqM0RTNXBlOHUweUdITG1yUVRoVCtFSmM4RVA5TUFBTndQcUN1UmxC?= =?utf-8?B?Z2NGNFhEWThGUFRJSHh3cFQxWG9DT0d1L0p5RkMyN0FXTnF6cGRIY1JhcVc0?= =?utf-8?B?M3g2Y1ZIcVdwbHE0QTl4dWF4alRrWWRZd2ZZeDJ0UEwwd2RlK1EvUjExY1M0?= =?utf-8?B?MHhocjFSTXNvQmx4TUJtMnRyMk5KOGY2bUwrcDhGVEN3RzdBbWdiY2pDMG5L?= =?utf-8?B?R09aOFJUeDhhRmpsTXB0b0Z2MXdrSXYvMC9rVUlGLytPaUk5THQvK1FuOEdE?= =?utf-8?B?U0NsUjUwbVVvb1ZFampRSGdhRXdYZ0Zmandyd1dNc05vZDZCSkpNNFU2Z3dC?= =?utf-8?B?bDNVR2Z5RCtRaWpxcUpheHlRM0JZV0R5TjRaVDlVYmdKeUxWTFRLWi9pNzNX?= =?utf-8?B?ZEppNjdvOHlDQXJJZG5jbkNMMEp6bElMakQxTEsrNzhXTFZsMlAzK1NxNjBL?= =?utf-8?B?b0VCM2IwTEh1eC82YU85TnhJYVJFUERhQ2N2QkxkNHZlMFVkOGU3VFVwdnRK?= =?utf-8?B?S3ZuRENUT3ZuQWh4dVJZNlNqZVFSRjZ0NjZrR2tZbWtVeEdFbUFodTVhdmNG?= =?utf-8?B?dU96aUVzL1JETzFGMW9aVVowdlRLSGQybEF3SlZtY1FaOUtzZFNGdVZ3STc1?= =?utf-8?B?M1F5MkFyVWJkSmdCYjBrc3h5TjQrbUpDdlBkdUxSekxOMFRRVUFzRTJEakI4?= =?utf-8?B?VHZjdHFLQlRrV25BZElyY1d6V2l2a1lUV1FMcUVwNmdlaGFhV2dUL0wyUGh6?= =?utf-8?B?ZExyOWFrUXBLWDJRSjhsM1ovVHJSZWZDSVpnbnZ1eW1RQVZxdFJoOTJGbWwr?= =?utf-8?B?cTlHaEdQTUpsYzJXSTZWalB4QWJCSTE3enllMTB2T2dnRFQ1ZTBVSTJPSTZo?= =?utf-8?B?cmhLS2tEbEFmNFo4ellKT3l3aGo5b0xhUHhkYnkxWVFRbDdUVTBMVllhSFg1?= =?utf-8?B?YlBiV0xldy82RU5DN0dRSFlhOUJxSDdGS2xlcmFLaFJETUJtRVczZlBXU3Zl?= =?utf-8?B?bVhNWHY1bGYwQm5qbjliYUV2Nlk4enRMQVgzdEFPQllGSGNlRFdlR2VaZkx5?= =?utf-8?B?YjJjOTdxTmxKZVVyZFJLYlFmQ3B4cjk2bUgwaVRjZmxXNERKSXUzbytOSkRw?= =?utf-8?B?MTVYcFlJaVluRy9sdGNiTzBvdUVYaXBpeldIVjJwdXhuUG1McWpZc1UrV2NZ?= =?utf-8?B?RW5WLzdhbkl4UGpCcUxUUms4SFVXeDZIV0NHNEY5MC9MSy9zTmppVG9NMzc5?= =?utf-8?B?R2paYWtoeXZaMWZKb0hKSi80ZXZERDhUNjJZRyswM2ZLS3FPL3AzRGh1VHhF?= =?utf-8?B?Zk1adW1YeXEyZ0NQL2hDaTdzU1hKeEpJaXFHK3ZIN08vbmhPbURGQjNJSUY5?= =?utf-8?Q?szlGlCyhYwKkjWyP2guBiqytv9CpYZEw=3D?= X-Microsoft-Exchange-Diagnostics: 1; TY1PR0101MB0985; 6:iMHDE9ODpae+Sg/0F+nF27e/IAeV236FxkGt4LFBA11AWdIgQ9f+2TBJhtQDQi4rYY92RDZIWJyRqWYG+tq9kp09KARE+tAAlRU1uOn/z4CMOFWeTeHhZpHZvJJnz0KOMi9mTdoO/uNxOCry1ER0YSl2SGCTKzbebZRgWKTc5uL49wqAi+1eSV1BnuKkL2EvlvxlO8aPfDKaPEKb+k9kMtNp+VPKGMwlSoMjh82shYRMcAaYJEzo/K4hq3sZDBHUNV5ak/NewMWzn05J5pL/4zAocxK4MiqnAVJUXgU5g2vcf3CO6EVm4m/HDxLSfgbc+QaZUJkeYasS3GZMrScsTw==; 5:H8EEX7JXeTzUB5ebDKC1uCCCcBi+vHLlrfxenbeZNXE7chxT7+OayAhbTaOg/rrF3/UvfnJ5IGdMPnXZtsbDpRiRnUmsgO/jYIWybMMpMiOIbN2V3fRIzn+Zy0iTe2G4KnSEboL5ZiwILzTabFfCuMkP4hjPVFwd7EXJi+eVqWY=; 24:RQ3NAAhlr0XJ1McYfZog9+nTHVOopX+PK9o3WfzmT75iGWd3NU874oOv08HwgYvY+iXfNWkvTlpRyfznVWTCPB9LYpI7phCnF0FhpDA6bLI= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; TY1PR0101MB0985; 7:Zgtntvzq9VEw0ISujWbx+/fg80ewIlKX0XUPgqhWOwvY56LnHSBKDxCvArItaEn5pNEl9sfYwUKBKLgXqhu3MZUyQVf1pLdZKXXb5Vv3kCDwaWV8ORaTeKyzvKXK4mdfjDSrmmxbLj6jxEhpq54QW27y/NQ0OwrI6FSi91GMVOK+IEwNS4+HM5Oj4hSn0Xv9qTp/SbIf0Ij7WysXNNPsWUJDArVOQlfdujchMhIqkS2GHLeQAoe/VPqbGVWSd/5ctQhY6tqd97OMaj9zycWQVTCXjWjv2jLChhf6aYLu8uHWjLaU65q2uaFYEdJxcFVZcH9/FKDFv1UZRn2aGOoPyHKgRZhuVmnVG3S4b9Rr5JM= X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Oct 2016 09:17:00.7259 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY1PR0101MB0985 Archived-At: Cc: ima@ietf.org Subject: Re: [EAI] [IETF] Content Issues [ X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2016 09:17:11 -0000 Hello John, On 2016/10/17 01:55, John C Klensin wrote: > --On Sunday, October 16, 2016 6:48 AM -0700 ned+ima@mrochek.com > wrote: >> Like it or not, that's not possible at this point. Perhaps >> that will change at some point in the future when the >> penetration of EAI has increased, but until it does the best >> we could offer is to allow EAI addresses to receive the list >> but not post to the list. And I don't think that's of >> sufficient utility to bother implementing. > Yes, exactly. Even for the "receive but don't post" case, it is > worth remembering that just including a cc to a non-ASCII > address on a message, even if the sender and list addresses are > all-ASCII, or having non-ASCII in the headers when all addresses > are in ASCII, is sufficient to prevent many members of the > community from receiving the message. Agreed, but the people subscribed on the mailing list don't appear in the headers of the mails sent out to others on the list, so that shouldn't be a problem. > I haven't thought through > the implications of IMAP-accessible archives of messages that > require SMTPUTF8 capabilities, but I don't think that would be > pleasant either. There may be a time where we have a few remaining people with old IMAP UAs that may have problems accessing the IETF's SMTPUTF8-capable IMAP servers (if there actually are such things). In these cases, these people may have to use the Web archives to check these mails. But that time is definitely well in the future. Regards, Martin. From nobody Mon Oct 17 02:21:56 2016 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86AF412944E for ; Mon, 17 Oct 2016 02:21:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DU_uMrA2uPyK for ; Mon, 17 Oct 2016 02:21:53 -0700 (PDT) Received: from JPN01-TY1-obe.outbound.protection.outlook.com (mail-ty1jpn01on0109.outbound.protection.outlook.com [104.47.93.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 985BB129477 for ; Mon, 17 Oct 2016 02:21:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector1-it-aoyama-ac-jp; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=8y8lRICp1U6OJy6FUcKhW/I6kjGxVJ1hNPQuIGGWghU=; b=sE2CYkJfAJfDHrnOY7umrrBohcRlMFfShHjCGHfXNQFkXZpRWN1XqjjEwV0dfIfClESkaHCOzpGawBDTsgArEA+QUszBEjr7OKgfLUfDUNxGm7Pgvnc1xfn2HzEXiHqjvTlFDGPgGEeXYouPFZP4OmlEzrWYOjkczONDA4xaQxw= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=duerst@it.aoyama.ac.jp; Received: from [133.2.210.64] (133.2.210.64) by OS2PR0101MB0977.jpnprd01.prod.outlook.com (10.167.178.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.659.11; Mon, 17 Oct 2016 09:21:49 +0000 To: John C Klensin , Shawn Steele References: <01Q668S03W0W00Q5OH@mauve.mrochek.com> <532EC6872314DFB0CC2B5F46@JcK-HP5.jck.com> From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <2512c1b4-19b3-9b53-c2e7-bc5a5f15179b@it.aoyama.ac.jp> Date: Mon, 17 Oct 2016 18:21:45 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <532EC6872314DFB0CC2B5F46@JcK-HP5.jck.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [133.2.210.64] X-ClientProxiedBy: TY1PR01CA0105.jpnprd01.prod.outlook.com (10.167.154.23) To OS2PR0101MB0977.jpnprd01.prod.outlook.com (10.167.178.143) X-MS-Office365-Filtering-Correlation-Id: 168e435b-dfa8-4fb5-781e-08d3f66f064b X-Microsoft-Exchange-Diagnostics: 1; OS2PR0101MB0977; 2:bRcsBi/xAi2eiVPnR4GS9TW8UGgarLBbbGlMMK+X4kxaMUlK8A3QV4ucGR7XJybFuFakLE2z4LmBDEXr6ZiaObrCC7JGq/TTC2Y9xWEaVg3aSZ44r4DzYATkhWuw3xroWLtnvNdJdWphOlxauHcYNqeVcEh3BWWdcI4ltl+gFgPuPg1ykAM5Go6PAbfQvGs+4+7IeGyPEp59CBvykrY6ag==; 3:mYmuSDtut4IyugeyyC0ultFb79iLH0fAwOCe3ouC9p5/v6ynOyMqDs3OIM+rPfF3CQ1n8WjVIudTCNhyUAsCD50G4By3WXGIKfIFkGiLthzUPtWRccVVl31CeaRj82eaCy/4iv/VzLjGfP5l93a7gw==; 25:QRMn0hmf5lQQHXQod9jTV+/skZKD4oZV9eRVf0FA1C9h8od5vAWQtQ8E3PDD3suOaKjDfdIcAr21bzlycoDCKwq0wsBzZGPIFiTFdMYcd0mvIM0df7V3HRIXOjFjI51yhdQJYLrWN5yh+ZSNzx+/y4iCIb31Yu4sl84qYDNx68VlWSIpAu4ZkvGgSl8NAkUSKDvfS6w3/UeqqzUfqV1avABxygFmRJdrWWyrk7Catb9osX9R4XWCwB3yHOAlkO+W9f5MpekGJYp0HLn5MrHm0khey81LxzYl1ma8SQ8sRLNEIz9YfogQ0MDOysDNzuIObrBvGjJ/FffPTpvj0B0Du7EpUe9m6p/yEtnIuwaGqKNxQLA+l/i9bPb40Aa+gQyP+DKWgFPCFbSeJgM73ZCy/cYKNyUuf+H/teVfj9HfCPnwm0DGNbsOAj4PDR/+fHB6 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:OS2PR0101MB0977; X-Microsoft-Exchange-Diagnostics: 1; OS2PR0101MB0977; 31:9ViMn4qt+0pFmLjqNrE9JizSGDpkp4WZLb+BEhSZq1wHgStMzXJMUb3yC6isB3g5i4E2NGg4SqxPgiif1JRutIL5lrFINPyUeCUJ25EGmocptbtmETckl2cJDcMeTU6VivYuGMer0Kgy0WbwsRI5C1hcAXL92H80vWNDaj3hAg75TPBwJxG3UGrzik4JFfMEgJvpln2JNW5/OdZ0Xs4U+PWvbztwd+JE4yPbiv98ClKaoZPO136VtTEztM0pJBLtr9dG/0JAxYCUX1S26CyP/Q==; 4:eOJ4Exjz1JXbL6HjOjIEMudr3ry/EDPj6IuGe4WTNZ2mJwu+3LV2qY3eUgqGoe1NxCGWL0TMIvMCOI6Jni1j9L834FkeN94TCd2ptDj53kleuF94H3nSiLlwgR0kuQ9hu7s8KfaJEJQUV5Q9ylpE62S4pFdKoWNhH/qZuPt4e+SGDOL0yVNSyw/r+JVuNxi44w7Yf1du6EAqHbyVwdn0c+oFT6AORC4OMSqrDqnT1QOUTrPCSXqDI7VuiMBAg6kokR/aJVfNsfdS4wm+Jn0IlatGGEmiWrT4V+LWTYHgAAhOgTcZ6xEsx9OgDs5V+VSpXkHvEwSSTjpgTd6WiVsQQhSFzSzulZVOf6U5D5zdyUPajlDnJTpmhZayMhMzx1KTpwpoJp4bL5OOEoOGDuAOo8+XUNUJibAZztN0oAwNKxg= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6042046)(6043046); SRVR:OS2PR0101MB0977; BCL:0; PCL:0; RULEID:; SRVR:OS2PR0101MB0977; X-Forefront-PRVS: 0098BA6C6C X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(7916002)(199003)(189002)(24454002)(377454003)(31686004)(2421001)(83506001)(2561002)(42882006)(42186005)(5660300001)(65826007)(189998001)(105586002)(106356001)(77096005)(68736007)(4326007)(6666003)(2950100002)(31696002)(64126003)(2906002)(3846002)(6116002)(586003)(23676002)(1511001)(101416001)(5001770100001)(230700001)(97736004)(19580405001)(4001350100001)(92566002)(86362001)(74482002)(50466002)(47776003)(65956001)(50986999)(76176999)(305945005)(81166006)(81156014)(8666005)(65806001)(54356999)(33646002)(7736002)(66066001)(7846002)(19580395003)(8676002)(93886004)(3940600001); DIR:OUT; SFP:1102; SCL:1; SRVR:OS2PR0101MB0977; H:[133.2.210.64]; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: it.aoyama.ac.jp does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtPUzJQUjAxMDFNQjA5Nzc7MjM6emlQeHQ0MGR0TzJENGx0cllubUlNSE5n?= =?utf-8?B?QzVoN1dGM2NOQjhiYytSL2J3T3ZQczJSSDMra2xlQnFzOUduUHZDZ0k1SWdk?= =?utf-8?B?L3cvczBqMmZDU05Ha3RCUVpITEY0OVVlWjVuL3FobmRsMkNkNXZlQjRaandj?= =?utf-8?B?Vm8zelNXdVlyL3NsRFdiQXYycmdUZEpqL2RXd2F3VUgxOFM1MFlkaS84UTAw?= =?utf-8?B?Mkc4WlBWZHc5MzZxdXl0Zm5VUGpZcDdxQkdmd290d1VLa1ZZRDRiYlJYYWVk?= =?utf-8?B?dG1Hb2NrUnRWWUFXbmJzUmp1QVhxMGFKVmRPSGE5aVlMK2dzU3BlTThtejlX?= =?utf-8?B?NjE3U255V2orNlMyb3BhZ20zUHRCZUZBSzNEVGtLYjNHMDBhOXcySU45cldt?= =?utf-8?B?L3d1WTZLRnI4d08xMDY2K2piL1QzNzQ4UjZsSUFTNDBreGtkR1JQemZEdUxT?= =?utf-8?B?TXhlOG91cmRLUVJvcTFWTnhaM3lSU1RFeWt4Z252TVo2dGhaQjRSN0NmZzgv?= =?utf-8?B?VjgrMGdvSmpqanNhMzB6OWNRcTV5YkVpdnNta3RxTDNaU2VEcjJKTE1XT040?= =?utf-8?B?aTBpL1oycmp0RHFLT09ac3BDUUg2OHZtOFFaRnhHSmw1djRzZjhzK2k5QVdu?= =?utf-8?B?SW9DR0p1eVNIazJ1ZWxMdWl0cEM3anRQUXRmWEhJUlAvSnN6bGRZcWFaNkR4?= =?utf-8?B?Z0ZFYmREcmZ1NjJYZ3pwQjNqTkdZa1N5YnNERGd3clowZ2tEMThoWWoxb1Vh?= =?utf-8?B?eGlYeTZ6VTdHNWxYSVBsajNUQVdYZWFKZzBJKzNzOWtreUY1V2RrN21LU0dU?= =?utf-8?B?VUU5UkRjR21YUVpMa1dPbkpWQnZKSFN6L1I2UFV3dU9PUzNmS25mNGZERmo3?= =?utf-8?B?dG9hNjVGeDBpclIvSENNVFdWNyszQjM3RXl4YkkvZzFmeWpSci9OOVFrUXl1?= =?utf-8?B?SmpGWU9YQkFMS2dtUHpsUkE2UHZzSng4N1hpWW1KMjNqZGpyYmZ0RTZwUzFs?= =?utf-8?B?SDJ3VGgyeThzY0RyWGpkR2gxbVF2a1c1OHpYa2FDV3hlYjNwamw4VFVVS01y?= =?utf-8?B?WTh1UE1tbCtzZ3FCRnIxVTdYWjlDeXZCS2hBNDY3T0h2M0U1ZytaN2V3SU4v?= =?utf-8?B?aDFYcG9xS3J3SURHS1FsL1dDaEowQUJiV0pWR0c1VFpBRytHTVpoc3dqTGM2?= =?utf-8?B?M1BBYnBQWjBJKzJCMjBiRUF4b0trb0dsaUVXWU94TVZ1enEveEptem5zUUZq?= =?utf-8?B?bEx1a2hJTGhHWnpDeGp5T2JCZXAweXF3YW5FY3Y3V0hDWmVaZDNHMUkzZVJB?= =?utf-8?B?KzA3TGhLcCtycHpxemJNaXhTZmJWL25FRkJBVVZBOU42Y3hlbUNIOGU2MndD?= =?utf-8?B?aGNTRDVaUks1STdQUEViUkNTaFp3a0pka0d1Q2UwcTgvd2xtZVJQVE5WTFpo?= =?utf-8?B?L1VhbThtLzBMT3pnK0xyeFk2d21CNldCUS8yZExNRHh0Q1JMUXZ2WGc1TjJS?= =?utf-8?B?SDc0bUFxdzBKWUtXb21NZE9ZMDRmWWx3UWVvckpBWEpheHYvUDZHckZxdHpR?= =?utf-8?B?b09vOUNPSmIwTU5oaXV0NWpreHE3Tlo1Z0RpcVVVQjV3YUcwQm5ob3JwWG5H?= =?utf-8?B?alRDV2E5aThlQU1mVG15NXJZTUd0czFJb091cTk5RlRmazUyTzZIbzZUbHNn?= =?utf-8?B?WU5ZS1V6RUgvNWxydzVSd2tZTDJLYndHa3VmUVRjem42OVBOUXdQRU5yRmxY?= =?utf-8?B?Y2lwbzNDSFAyRXRGYmcySE1jMzhya1N5aTlBT2szRHVIUlBMRkVpa1kveC8y?= =?utf-8?B?cTJJbks1RGJPQ0VtbE4wc0FGek9yYWNibUlrTE50VU9jT2J4dWtUd2c5a1k2?= =?utf-8?B?MDl1RndtdGw0VVdMNUh0cE5xcVJtajJDLzJLK3dKb29aa1QrT0pPQTFHSzY4?= =?utf-8?B?MUdNMi81Vm4wL3MydTBmU25maHpsaFVqZ1NtS1RGc01KdlFoTUpVZ1VFS2Fh?= =?utf-8?Q?jbuk4woc?= X-Microsoft-Exchange-Diagnostics: 1; OS2PR0101MB0977; 6:rUrRD285BLdu/+oi7/QmV0Lf4bcEw4YMn2IkgxzAhz4ancmT06/4Q5N7HCvjr4OXpW7L8+wfeg2rUoeOeW8DYkiWYzd/yINdrbTT70Nq1A8yXY8fua5j9UpC0ovCvkFPD2fFuapWbirUjZKRJTChHeTjsHRUFGN3WudM0Zrg1MrgLm/iciPaPHSlMPwnBfjeRQ/qN3SgQvG6ylCYaY6C0HUJXrRjmAvDF3N3r0RuR5kAvTTiOt+Dhzes3I8pOHTjipQgYMIKk+o7+5YHV8KGPmAXZhlThfgbcudDdJsqCZ0F1FGqTkSnu3HWOv6eoJcrxAj1v63ehBnFlN7N8FJ1BA==; 5:KOPkTzpLDQlPhTZ8V6rU56Qt4kysmJUl4jmwpvFRRQjnl98Tm0/Ob23NFvTvSoMmpfjjlOy1F9Pps13LD+sNdbJdVdJixQHf/rc77mO6xdcrRnpj57PWjAXdb6wD2U/A7ChhCjPwKuc7viJVoXTZMO8Bw36aRry93i285kjSIzc=; 24:RPuuIrGWRj9syHbScs5OdC1tGRNT4bz6uWLKk8Nn95f28m/mpDvwt71ftOqC0h1q91NtnCm8a7UJeyVq/DUD5OyE1p3usUiDywWkodpot/Y= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; OS2PR0101MB0977; 7:jWwfTWpooNa1Gg+udQKr+Q5rL6Ng80XNGn8cSUlTGDn1UdcY/J4PxogajP53tcj8tAyHBcIm2E/IRa9dONa4Oh9fEch5qExupFSFieYXrIJEvtOsVEzuX0AXrRij/P9Ydawq7ZmDor+a90uoapKWxRNKLb6fNWZsgr+y40P0nCnqKlbQSkFjPrYUEy2vUQALRLeAQ+lpSUTl9J4/Pt+d2rcEOGE5GnBrhqtziEzMLPWvf9I7jrX4pheUiDcT5cgMJoRjSFcwLfVdk8TWyCz9fWtqWzVcsHxl+tZdq0S+m2q3APxBZUfmlNv0PRQ+/vd9WaRHN8XY4LIAUd47sDun8dyUh96wTt4LJQ1EFbp+1vQ= X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Oct 2016 09:21:49.0267 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: OS2PR0101MB0977 Archived-At: Cc: ima@ietf.org Subject: Re: [EAI] [IETF] Content Issues [ X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2016 09:21:54 -0000 Hello John, others, On 2016/10/17 02:24, John C Klensin wrote: > --On Sunday, October 16, 2016 3:39 PM +0000 Shawn Steele > wrote: >> Certainly there isn't anything blocking the digest version? > > As long as the digest version does not contain non-ASCII > headers. Remembering that the EAI specs encourage getting rid > of encoded words in favor of Unicode in UTF-8 in the headers, > the digesting mechanism would have to be able to translate > non-ASCII header information back. That is certainly feasible > but I'm not sure it ought to be our highest priority. I think this depends on the level at which the digest is processed by the recipient. I haven't used digests much, and when I used them, I always saw them just as a concatenation of the mails with the relevant headers. In that case, they are just plain text, and should work well with UTF-8. Of course, for cases where digests are elaborate multipart constructs, and clients and users that want to act on these constructs, that's different. I'm not enough of an email expert to know how important this kind of use case is. Regards, Martin. From nobody Mon Oct 17 02:24:50 2016 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E82B129477 for ; Mon, 17 Oct 2016 02:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.433 X-Spam-Level: X-Spam-Status: No, score=-2.433 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mQB6zqFNl4mY for ; Mon, 17 Oct 2016 02:24:48 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04208129426 for ; Mon, 17 Oct 2016 02:15:00 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01Q67D2ALGF400WEYQ@mauve.mrochek.com> for ima@ietf.org; Mon, 17 Oct 2016 02:12:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mrochek.com; s=mauve; t=1476695523; bh=R8JvEjiZgfqi1H7r9Lqqu+6K8YoJQahDf0O97nsC248=; h=From:Cc:Date:Subject:In-reply-to:References:To; b=LTII+YdSb6EaEYR+NUI5RfkzLV6wSYlpr8/Y5U6wz5VRA41vTomsEYWkr0o4SlG0a K2Dr8IGMbgKrJ1g6jcVHRmXSBCvu0kB4oGr9Ik84fOFSegWx+4DxSRpSwfIC617T7g EY0LzQu077ebuP6BWSy6/X5GaR92zmz0Uf/wm/74= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01Q64TB541DS00Q5OH@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Mon, 17 Oct 2016 02:12:01 -0700 (PDT) From: ned+ima@mrochek.com Message-id: <01Q67D29CYCM00Q5OH@mauve.mrochek.com> Date: Mon, 17 Oct 2016 01:58:46 -0700 (PDT) In-reply-to: "Your message dated Mon, 17 Oct 2016 00:22:54 -0400" <7FA831D4B3709857DB95DE56@JcK-HP8200> References: <01Q668S03W0W00Q5OH@mauve.mrochek.com> <532EC6872314DFB0CC2B5F46@JcK-HP5.jck.com> <783239201.731221.1476648090891@mail.yahoo.com> <7FA831D4B3709857DB95DE56@JcK-HP8200> To: John C Klensin Archived-At: Cc: Harish Chowdhary , ima@ietf.org Subject: Re: [EAI] [IETF] Barriers to Deployment [ was: Content Issues] X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2016 09:24:49 -0000 > --On Sunday, October 16, 2016 20:01 +0000 > nalini.elkins@insidethestack.com wrote: > >... > > I have also been following the discussion of the subscription > > to email lists. I think that joining such lists is one of > > the important uses of email addresses. I was just talking > > this morning to one of the not-very-computer-literate older > > ladies in the neighborhood and she was telling me about how > > useful she found the neighborhood email group to be. So, I > > can see that this is something many people (not just IETFers!) > > probably find useful. > Note that there are a couple of things that are very different > between a neighborhood email group and the IETF list. One is > that the same requirements for transparency and accountability > typically do not apply, at least in the same way. I think at this point in time this is really a matter of degree, not a brightline disctinction. At this point in time the level of support for EAI is sufficiently low that it makes use of EAI addresses on any nontrivial mailing list problematic. > The other is > closely related to what at least some of us have believed all > along would be the normal deployment model for SMTPUTF8, by > deployment within communities, particularly communities with a > small number of shared primary languages, who conclude that they > need it. The problem is that communities increasingly no longer match up with email providers. The obvious example here is the ever-increasing concentration of email users on a ever-shrinking number of providers. In theory this could make EAI deployment simpler, but in practice only one of the four in MAGY support EAI right now. I'm not happy about any of this, but my lack of happiness doesn't change the situation any. Ned From nobody Mon Oct 17 02:27:35 2016 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EF561294F0 for ; Mon, 17 Oct 2016 02:27:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.433 X-Spam-Level: X-Spam-Status: No, score=-2.433 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yf6t5YSULelN for ; Mon, 17 Oct 2016 02:27:32 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 797E0129477 for ; Mon, 17 Oct 2016 02:27:32 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01Q67DF8JYQO00XBMY@mauve.mrochek.com> for ima@ietf.org; Mon, 17 Oct 2016 02:22:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mrochek.com; s=mauve; t=1476696149; bh=gemCFMQMsDs3qFhADOXatYmvm3c1BG+p4x+3AkCZmBg=; h=From:Cc:Date:Subject:In-reply-to:References:To; b=q7kR9vDWej70yKscjQeWFr8hxLFxGEd3Z6qFu5/2FEkWs3dHFV2ImQiGjlh/tQHuX jn2n73XRdQCwiLJ7hiU5sdZC+42Fl2jkfauH3Z/9/fesRqJmZxTEzwCBQeVtcUuzWD Lz13STIxhfc2pqyUj/fvyUgqHyaY19MHpJRH8Eo8= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii; format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01Q64TB541DS00Q5OH@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Mon, 17 Oct 2016 02:22:26 -0700 (PDT) From: ned+ima@mrochek.com Message-id: <01Q67DF6I3XC00Q5OH@mauve.mrochek.com> Date: Mon, 17 Oct 2016 02:15:50 -0700 (PDT) In-reply-to: "Your message dated Mon, 17 Oct 2016 18:11:03 +0900" <7f7ec0f8-2a3a-43e6-ebfe-117be6877a13@it.aoyama.ac.jp> References: <01Q668S03W0W00Q5OH@mauve.mrochek.com> <7f7ec0f8-2a3a-43e6-ebfe-117be6877a13@it.aoyama.ac.jp> To: "=?UTF-8?Q?Martin_J._D=c3=bcrst?=" Archived-At: Cc: Shawn Steele , "ima@ietf.org" Subject: Re: [EAI] [IETF] Content Issues [ X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2016 09:27:33 -0000 > > The effect of this is to essentially to create a EAI-capable subset of any > > discussion. That breaks accontability, as John notes. But perhaps more > > important is the fact that it also breaks the entire open model. > Well, the message would go to the mailing list archive, which should be > enough for theoretical accountability and openness. You're ignoring second order effects - the fact that only a subset of subscribers will see such messages and thus have no chance to respond is both intrinscly nontransparent as well as inimical to the accountability provided by full and robust debate. As for archives, unless you can produce evidence that a significant fraction of people actually regularly review the archives to check for messages they might have missed, I view them as irrelevant to the matter at hand. > But of course, a > mailing list where contributions from some set of participants to some > other set of participants regularly disappear in a black hole don't make > much sense. It's a lot more fundamental than that. See above. Ned From nobody Mon Oct 17 02:28:49 2016 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CAF71295C4 for ; Mon, 17 Oct 2016 02:28:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dh9AAF_rcwUV for ; Mon, 17 Oct 2016 02:28:46 -0700 (PDT) Received: from JPN01-OS2-obe.outbound.protection.outlook.com (mail-os2jpn01on0101.outbound.protection.outlook.com [104.47.92.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4151112944E for ; Mon, 17 Oct 2016 02:28:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector1-it-aoyama-ac-jp; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=XT0rWrMS+VdGHym+BAaS2far/7A+KWEOpgFsbVvgo3M=; b=q30kpqUz0c8VwZFRjimNcTi+Yl7XaBt4IaYEAUc3NvBxPcRhf4Td6n7Rjg4TURfeCcf2l/w/CaY8/nSq4XQV0WU5RkgC+e3ECMk9TDXDxPaFNevnviVCgmU1aucyy7EDVNLTyIWexDK8aasB58S+wvKFGSrAy7ECdFqT8Wvca2Y= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=duerst@it.aoyama.ac.jp; Received: from [133.2.210.64] (133.2.210.64) by OSXPR0101MB0982.jpnprd01.prod.outlook.com (10.167.149.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.659.11; Mon, 17 Oct 2016 09:28:40 +0000 To: , Shawn Steele References: <776420919.20161016132653@uanic.net> <01Q66PLXP7X800Q5OH@mauve.mrochek.com> From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <2f03e34f-36b3-4d9f-44b3-de21d008cfc6@it.aoyama.ac.jp> Date: Mon, 17 Oct 2016 18:28:35 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <01Q66PLXP7X800Q5OH@mauve.mrochek.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [133.2.210.64] X-ClientProxiedBy: TYXPR01CA0006.jpnprd01.prod.outlook.com (10.168.40.16) To OSXPR0101MB0982.jpnprd01.prod.outlook.com (10.167.149.16) X-MS-Office365-Filtering-Correlation-Id: a062f5f7-98af-48f0-e1f3-08d3f66ffb73 X-Microsoft-Exchange-Diagnostics: 1; OSXPR0101MB0982; 2:YS0PyvggQuRCW0WmoXxZfswGi7ca5Zguys0snQcrO9ebldjD+/6Kk8B6Wjj7KwTHJnqlmRv4G7o1XZoy7gjkbWP38e30Cq8wvnfMdNe8zzAY8zgaYntf4RLA3nqKYlU2ea/fJjBqfbAoMW3Eijk3509ygdWriiB9Pta1km6Q6AEmnRIrapgQuEmJHbiYdTrA6Cd1zCqkAel1VS856ymUow==; 3:eQx7J+118r6m/wTTZBKwDT5wa1IdCD/YXRLfh24gSz9ouLUsruVKuBpxcOKJ6MaLeBTo1uMm4dYcETD9Fjw1WpwnrqU8ILg5/iCfIERATgF8mPKQOp98qJZYhthyRM38uL5jhy6z6vwaifPM4ddXdg== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:OSXPR0101MB0982; X-Microsoft-Exchange-Diagnostics: 1; OSXPR0101MB0982; 25:MJBSyew4Fv82cuIwuP3+6k69KGJMI1BkITZwFBRLxHmgw62V3n43N2pyTYzaCcAD0D4jE5fqeuNW0d+WoCU4nGEBXPOSZa+583L/orDRbT1oQ/fm+sz/dduLtfomoBEUMbW/N1hSkm7LVojHkupwwLIV8vgBVZ33bGiyGDknW4LVxT1UyOGkpg1bpLaKssUF6xxiUTy4eqScQchsyxt3qTZ9v6DZ6zDNfrrWxhn9Hp/4p6oqejWsIpxgQ3tcmDs0Gm6C/bzQFcZZd1Vvol+ms1/w7YVsRGaq1iiNQiEkfYsz9OF9M7fC15ndHPircukNMzchruj2RVUz9KegU+1KcFuufzb1BGFW3D+fr3DQkc3lI0qPGXkZznGpKHrkzBCyW50pza5YF0qSkEIiq1NvppkUEkG5wcjk/aRqICwC2PV1dBgQXohQLoqnajBT9ftbQfo1dt0IJlKG0QcKz6MT6J2YUKwgVziwfYUwmAx5rwVX2bdexM6ydD/gbwh7UwV9pvojPIrpEnsvXzgovsxVwY4Gyry4Omx2qebj7YvujR3fy4WQhEZTHKQGyDioH4+GvrlMfbLRMRpADmqCxV7JD85leU/QLPsHB2PwFE+ungd07PInLmWuyxGNxmWtJjlDx9z+mSVz+39/7z8FyH8OC8m9cOPOLy+lJQvRe+S4nqikMMiHNmwKuK7Si6XAXglTTkEFTuFWxDI3vYXlwjBfgoAbJe/m8dlHbFzpDs7VjjDsIViSt+lcN9yosDw+DXRR X-Microsoft-Exchange-Diagnostics: 1; OSXPR0101MB0982; 31:ZPDEJ+Jf4m6awH4vu2uDiIW8iiO43ntlIE5t9wtY2eWtuKe6Ckoly2+15K6JPZUbvDdeKh5csE/UNzIYM8rgpGFXA1Q0MG4QSvoIXTnt4lN9709MkL+5iyFIflIc/kqw7jESG5V7+t/cwKDQ7+Q+672eCwb2R8GGfneBUXGkSYI4Tr4wD1+7vL/g72Vpw9SJQ1UizqCKSeGF8Pp90WZVmj/oBUE7M2135QCLN9KfiImLr7AIqYF/YlyYHbIYINcH; 4:TR8mQWw4GaaOZY2nNkDjPCT0QRIjZdQmWVQCqYAaFvaGUUFU8Wd0ERDaS8udH0Zv6vPej0ycOfVtLC/sqUPTmsNfmiacrX4gjEnihanf1WH6m7KsTC2TDoq7wKXsQBCRr06JU7NTCWP706tgK4R1rpa/Kui3m9IZqanV0clIUjrpFPqWyFBdXhnw2wQUiCxJqA1E/zUpb7rbnux9Vxjg5Axu5ZxmM42FZDi8xNDwJ9D0lQ3OxAFai2o+7lGbAtBscn0r+4ZHlekYYdeMZRss40hXcJVommSHOr/smAPz/17+BTJBhR0qomfeONTq6yFjPLnI+0IdYcUEi+jHunXS5KqZwomfNHY8EYdGZ4M2/0B7GfFV3lt0WOeGLmxXKi2UJztruo5RvpTQ4JZUVnX4ZfWG2scf+pI83BOWK84OGggHVpENNc3OCAXXkWFEZl1S8wnGei2tbt7VRRoyPazV8ukXuTCLCBVi6nLmkXuZAns= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(278428928389397); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6043046)(6042046); SRVR:OSXPR0101MB0982; BCL:0; PCL:0; RULEID:; SRVR:OSXPR0101MB0982; X-Forefront-PRVS: 0098BA6C6C X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(7916002)(24454002)(189002)(199003)(4001350100001)(6116002)(7846002)(77096005)(8666005)(97736004)(31696002)(86362001)(3846002)(93886004)(65806001)(65956001)(66066001)(2906002)(4326007)(64126003)(31686004)(2561002)(54356999)(50466002)(50986999)(23676002)(19580395003)(19580405001)(76176999)(230700001)(47776003)(68736007)(101416001)(1511001)(92566002)(8676002)(106356001)(2421001)(74482002)(65826007)(105586002)(33646002)(5660300001)(83506001)(6666003)(81166006)(81156014)(7736002)(189998001)(42186005)(42882006)(2950100002)(305945005)(586003)(5001770100001)(3940600001); DIR:OUT; SFP:1102; SCL:1; SRVR:OSXPR0101MB0982; H:[133.2.210.64]; FPR:; SPF:None; PTR:InfoNoRecords; MX:3; A:0; LANG:en; Received-SPF: None (protection.outlook.com: it.aoyama.ac.jp does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtPU1hQUjAxMDFNQjA5ODI7MjM6dHRRSWhkbkpzSzY3ZE5QOEdUcUxrK3g2?= =?utf-8?B?Wjg2ajRudnpyU3BMRVU0VXE3WVQ1MmR4c0J1Q25kRENlVkg3MmtNYVIrQVZN?= =?utf-8?B?dE5rOHZBMWN0UWlqemc2NWZtSndteGJxdzRFUnptM1Zpc0xqcW9LQW52OWZK?= =?utf-8?B?VEdsMnFiNDNiUWNCRDl1aUYwUzU0cVBIWEpKYkRTaXlBNGtPaFFqZU01Tmg3?= =?utf-8?B?UXUwYW03b2Q4c2tQOW4veVZ5ekNvWnBXNC9PZXo2TEh5ZGE2VWs4UnNzMzZX?= =?utf-8?B?b1hxbmYrc2pKRGduMEtpMFFla2NndXlZdlVSZDJuNkUzRisvZ25ocFdUQWdB?= =?utf-8?B?OUtzMDRoeDVyc1dnY1FhVDNtVlVTWWxraGNtUU81cTNhdnZXTzFFaVd0T2xD?= =?utf-8?B?RFZSWUF3V2RGWDdTeEdFQytQOUdQeEpQbmMzNnI2SjA5THNKbmgvd0toOEhs?= =?utf-8?B?SmJQd3I3VVBVdkdwWlZjRHFIait6azEyMFpXeXNkUkVsQmQrUmZPSng3V2Fm?= =?utf-8?B?NklyUkxlK3AybjhueTdUeGF1aGpmS1d2RUVqSDhEZ2tVaHVqNjRGajdPQzMr?= =?utf-8?B?K2Fvc0tvZzhUaVN3SkdUbjJLOVhsNE0xNEN3TnlPZWl0S0RYbkpEc0tBdHg1?= =?utf-8?B?NEhlRElJbHZnSy9hTlljVzJOQ01MTytDVXQ4Y1hzcE4zdmZxbVVwaUlpYUFh?= =?utf-8?B?eEcrN3RGSU5WVDVvNmt0di9FeTdkd2xFeW55RUdwa1BDWVVKTGdiK1lESzVY?= =?utf-8?B?M3JhMlhVR2VpT1Fwa2s3eDYzZWRqTDhsbUNVYW85cEZLeERMTVFmQTgrT0VP?= =?utf-8?B?U3RFMjVCSXk3UXRtTzg1QmZ3K0tPK1VBczRwd2t2bmdzTkM3Z3FGdmQ0Ukxn?= =?utf-8?B?S2RZR0Y5N2lrZWdWTE1lL2hZZ21kT3UwK1VvN3BXRW0xWXl4M1pJTk9Sdm5x?= =?utf-8?B?M2RhR3V1TXJXa1JabWpKMkl4Y3RKN1puN3c4TlBPaExkY2VNc21LcElmbjhG?= =?utf-8?B?UnZhdHB0cnlXekpiNEZoRWgrdDg0THlENVg1aWc5b3VZUjEvVmx4OTN3UjhV?= =?utf-8?B?VlJnRVlzVGZ3a2NrMCtOTC8zWDk2MytNNHlmWXhCTkFXUkN1R250amxNaDhO?= =?utf-8?B?ZVl3VUU5eGFwVGFTMXJwNCtqNTZzZWhhN2VielRFeGp2MXpaUFc3dXVkTnY2?= =?utf-8?B?TG1SdVRhdW45bkpJU3JZK1BOQTFJcm5ndHZQd1lPUmlya3d3cmFGQjRrTkE5?= =?utf-8?B?RjJIOFpiL0pNV0tEby9vbFh6aUZvLzI3RENJb1BSWnIrc3hPRkRPVmtRaVVn?= =?utf-8?B?M3lNRFNjc0hNVThNd2xRRVZLSDFSakJ4Q0Zjb2E5TlBkNkV1d2VZZ3BJM0U0?= =?utf-8?B?ZDdZNkxBaVBXN3Fmd0RlSWtDQWUyYnNnQU9IUndwSmNOVXRHRWE3d2tSTCs1?= =?utf-8?B?UG44NWtuek1aNXM4b1Q2MEN2akdIUTliandORDJVZmp2TUQvaURqUExGV0hv?= =?utf-8?B?OTZvSlovNkh2cld1aWhkY0VqZnNYM215VmllRzgxaCtpbFQrOHFlL3Y1ZEE2?= =?utf-8?B?aG5pb3JsQXZEY1hhcC94aG5UckErenVxK3ZRZkRuK25pbk9FeWtkWVB5NENN?= =?utf-8?B?dTVQc1NHbWVtWFdMck82anNqYyt0dGJ2S3BERkg0K0IrUWtvYnorWE9Kb1J1?= =?utf-8?B?U0U4WkM1ODNpWFVyRkZjditSOTZ5OFExdGg5QTF5RFdMeXRMaTdiSUZ4WCt2?= =?utf-8?B?amNBT0FFdm80d0RHVUhOdnNBR1dhNUtBelNqeDN0VzcwMVFhamFiaDNvb29R?= =?utf-8?B?TXJNcXFndTQ3WHZlejNUS0N2SjVtOFJkb1k2VlljQ2F6eHJqS29IRS8xUHNB?= =?utf-8?B?TmxDWHc1dnpwVTFHU2NRRG1TZ0VNUTBCbjgzWVpGdEpOeWtadlVpK2JvS2pn?= =?utf-8?Q?X7i3oiedP4yTKYrl3Mtlq2eZtHf3Ngl8=3D?= X-Microsoft-Exchange-Diagnostics: 1; OSXPR0101MB0982; 6:M24RFKNOGKnj17rKvoQLBEgGZZW2B9M7DjNHUhy3udaOsY7tKOvhABJlEhi4PTeuqEsiasiDYn/9Hx+BpXKmtzSu+7XLTITKR7BdQKY2Hg6fILXLAVxaUqgqy6sPNjjn0ugeXKhiUvSAqe4F4JEoSKao8/Ts6tF1apiXYc2xFYU2guevrE00GopZa42TDC/BfINyq4rLl5VHWIoCQXGXNaGQM4v0+Dm4ntGZV06xSeXE+ImLnY/wX14cmZqIy7oGGZQjMHh2DBlJswVt/lBXvTBpThj1fTDQNpCmGaT33LO+JYsajLgpdk8ZMfbk5oaW2NVWjTbGR84WuFMDOIkogA==; 5:qmdFMmARHGHpaIqr6G7PB76H/rTJA5e/FdORnJEN59PKt1LqCiLo9ulBVNQKX/vxqFvcHVI+AwlXrrEn5DL37z0tC0X3lnQ7OQ1pWYb1sCYdnK/bMxhevwBtB0sMW9femFgvHiF/GQHHuUFBJE5JtKg5u2dhzqq3NRCMO3lkgT0=; 24:vMmD5FLB048K2RoQcyyG2PPYkJ7zHzUla2DE4nCHRMi9hpYgKk5/NnoR9x/5P53lzyOp8ItDNVVzmxqupJBuaD7IE1Px6DmP1kizrHuatcU= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; OSXPR0101MB0982; 7:ePTPwuo0MXFKm39Y4gKSdOk0+y3PLRnohWaLhVNHMBcGfcH/TjDsYCJgP1E/pUt9ekoYnjn42elXHF2pKGtb/Jbg6NGDDxbVa7X97WXFeTr4d/r29ci+WigUmUIu9zyyG7KiEkwvyxpteKgs1kIq1XX93L4hhQ/80gx6OGkVMXAYnJvpEiJ7qWVTXxE/0lrZO1MEUqfXKAHY7tUrH30BmYA6NPh9hS/+kgLxCvY88pQO0XLVV+PsXOq/2pEpREVactAhv2RAiQLdHgJtNBt0etRSSA/ep85lrvgFH8kPQzGAFBHAwKjZRsc5zEp97s8CPNYROggHU9GDrK8dKdOwOW4FED6wCYQDoFeTgWIlcYc= X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Oct 2016 09:28:40.8329 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: OSXPR0101MB0982 Archived-At: Cc: "ima@ietf.org" Subject: Re: [EAI] [IETF] Content Issues [ X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2016 09:28:48 -0000 Hello Ned, On 2016/10/17 03:35, ned+ima@mrochek.com wrote: > Bringing this back to the original issue of being able to use an EAI address on > IETF lists, if you want that to work and not break our current model for > participation and accountability you're going to have to require that everyone > use an EAI-capable account and user agent. Even if you could get IETF > participants to do that - and I can assure you that pigs will fly first - > think about the added cost of participation that brings. I think 'everyone' may be difficult, but something like 99% or 99.9% will eventually happen, just because for most kinds of software, it's easier to produce one version for use worldwide than to uselessly divide the market. As for added cost of participation, upgrading something like gmail is essentially instantaneous and free, and upgrading something like Thunderbird requires only a click or two. As these types of applications these days form the bulk of MUAs, the overall/average costs for participation won't be too big. Regards, Martin. From nobody Mon Oct 17 07:16:38 2016 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46DDB1296EC for ; Mon, 17 Oct 2016 07:16:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.331 X-Spam-Level: X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D4PWOSAf3kjc for ; Mon, 17 Oct 2016 07:16:35 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E0731296DD for ; Mon, 17 Oct 2016 07:16:35 -0700 (PDT) Received: from [198.252.137.10] (helo=JcK-HP8200) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1bw8iG-000M2S-2z; Mon, 17 Oct 2016 10:16:24 -0400 Date: Mon, 17 Oct 2016 10:16:19 -0400 From: John C Klensin To: Ned Freed Message-ID: In-Reply-To: <01Q67D29CYCM00Q5OH@mauve.mrochek.com> References: <01Q67D29CYCM00Q5OH@mauve.mrochek.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: Harish Chowdhary , ima@ietf.org Subject: Re: [EAI] [IETF] Barriers to Deployment [ was: Content Issues] X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2016 14:16:37 -0000 --On Monday, October 17, 2016 01:58 -0700 Ned Freed wrote: >> > ... > >> Note that there are a couple of things that are very different >> between a neighborhood email group and the IETF list. One is >> that the same requirements for transparency and accountability >> typically do not apply, at least in the same way. > > I think at this point in time this is really a matter of > degree, not a brightline disctinction. At this point in time > the level of support for EAI is sufficiently low that it makes > use of EAI addresses on any nontrivial mailing list > problematic. Agreed. I was projecting into the future and into communities in which dominant email providers who do not fully support SMTPUTF8 were not significant (see below). If current trends continue, we may never get there. From my point of view, that would be really sad but, like you, how happy or unhappy I am does not seem to affect the trends. >> The other is >> closely related to what at least some of us have believed all >> along would be the normal deployment model for SMTPUTF8, by >> deployment within communities, particularly communities with a >> small number of shared primary languages, who conclude that >> they need it. > > The problem is that communities increasingly no longer match > up with email providers. The obvious example here is the > ever-increasing concentration of email users on a > ever-shrinking number of providers. > > In theory this could make EAI deployment simpler, but in > practice only one of the four in MAGY support EAI right now. If that sentence was about full support, including mail origination and IMAP and POP support for "foreign" clients, I'm not sure the number would be as high as one. > I'm not happy about any of this, but my lack of happiness > doesn't change the situation any. Yep. And there lies a very difficult social and economic difficulty with deploying the EAI protocols. Especially for a very large provider, support may be difficult to turn on (one may want a flag day or flag second so that all of the pieces of one's systems are either advertising support or not) and expensive to support (imagine calls from people complaining about an apparently fouled-up error message whose headers they can't read or even the additional organizational/management requirements when a question must be routed to someone who can understand both the headers and addresses on a message and the language of the body content). As Martin pointed out, if the trend toward use of email addresses as identifiers in other contexts continues, support for non-ASCII addresses requires support, not just in email, but in web forms and interfaces, in support for X.509 and similar certificates and programs that utilize them, and, in many countries, in assorted "fill in form" legal and other documents (including in form-filling-out programs that don't require real-time attachment to the Internet). Against those costs, the providers, many of whom see providing email as a necessary adjunct to profitable services rather than as a profit center, have to weigh the unhappiness of communities who want to use non-ASCII addresses (but who manage to use ASCII addresses in their complaints whether the content is in English (or some other European language) or not) against those costs, including the costs (both implementation and support) of allowing non-ASCII email addresses in non-mail contexts. In addition, those who understand the issues are likely to see risks from acquiring a bad reputation when things go wrong that far outweigh the perceived goodwill from accommodating non-ASCII addresses and headers. There will be places where the economics work. My assumption is that the number of them will gradually rise. However, in the near term, the right conditions are likely to exist only in areas (typically countries) in which virtually everyone in the country uses the same writing system _and_ the dominant email provider(s) draw the vast majority of their users / business from that country rather than globally. At least absent government action of the form of "you are not going to do business in this country unless..." (a type of move that it may not be wise to encourage), that makes places like China and Thailand much more likely candidates for critical mass deployment than many other places. Perhaps it is not a coincidence that the two workshops were in those countries. And perhaps when they can report to the rest of the community about problems encountered and how they were dealt with, the perception of likely risks and costs will diminish. We went down the SMTPUTF8 path to try to ensure interoperability without really bad problems for users of both ASCII and non-ASCII addresses when it became clear that, unless there was an IETF standard for non-ASCII addresses, we'd see a number of incompatible solutions with nasty issues at the boundaries. I don't regret that decision and think the result was fairly close to the best that could be done. However, we knew that it was going to deploy only slowly and that there would be difficulties until everyone had converted. I don't think that suggests we should stop trying and I've very encouraged by the intentions and efforts of Nalini and Harish that started this thread. I just hope we can move forward with a clear separation of issues (e.g., what requires, and is necessary for, non-ASCII content versus what requires, and is necessary for, non-ASCII addressing) and a minimum of hyperbole and false promises. I mention the latter only because there have been hints in this discussion that the absence of non-ASCII email addresses are _the_ barrier to deployment of the Internet to the next billion (or some other number) people. We've heard that before, first with IDNs, than with top-level IDNs, and, more recently, with non-ASCII email addresses. There has been little evidence that deployment of IDNs or top-level IDNs, no matter how worthwhile, has made a significant difference to the deployment curve even though there has been evidence that their absence was used as an excuse for not deploying more infrastructure or reaching more communities. Let's avoid encouraging the perception that the absence of EAI is yet another excuse to avoid Internet deployment. best, john From nobody Mon Oct 17 15:24:56 2016 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2B09129467 for ; Mon, 17 Oct 2016 15:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.433 X-Spam-Level: X-Spam-Status: No, score=-2.433 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rMLez-_-NBzi for ; Mon, 17 Oct 2016 15:24:53 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A85551293F2 for ; Mon, 17 Oct 2016 15:24:53 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01Q684KYV75S00B0WY@mauve.mrochek.com> for ima@ietf.org; Mon, 17 Oct 2016 15:19:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mrochek.com; s=mauve; t=1476742789; bh=COGJtQ0YhmyECtlxBDA1NguvhgfCutjY0q4bV3PbZKk=; h=From:Cc:Date:Subject:In-reply-to:References:To; b=VzXPUqw6CKS2cc9Pf7I+RelFFxMMkMhCGIJq/RmAM4BDmdWu3SsHcnJ2tqUFzqPsG VUzeFU0v+R+fBM9EgKO54Hi7kO5F9A1vKKfe2oGzgVM6WWqT3aapYSt/UZQAp3PwBN QJnvlk4IjJy0i6al6rP8gAgByNqvffyyNFybIxd8= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii; format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01Q64TB541DS00Q5OH@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Mon, 17 Oct 2016 15:19:45 -0700 (PDT) From: ned+ima@mrochek.com Message-id: <01Q684KWD5D200Q5OH@mauve.mrochek.com> Date: Mon, 17 Oct 2016 15:17:30 -0700 (PDT) In-reply-to: "Your message dated Mon, 17 Oct 2016 18:28:35 +0900" <2f03e34f-36b3-4d9f-44b3-de21d008cfc6@it.aoyama.ac.jp> References: <776420919.20161016132653@uanic.net> <01Q66PLXP7X800Q5OH@mauve.mrochek.com> <2f03e34f-36b3-4d9f-44b3-de21d008cfc6@it.aoyama.ac.jp> To: "=?UTF-8?Q?Martin_J._D=c3=bcrst?=" Archived-At: Cc: Shawn Steele , "ima@ietf.org" Subject: Re: [EAI] [IETF] Content Issues [ X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2016 22:24:54 -0000 > Hello Ned, > On 2016/10/17 03:35, ned+ima@mrochek.com wrote: > > Bringing this back to the original issue of being able to use an EAI address on > > IETF lists, if you want that to work and not break our current model for > > participation and accountability you're going to have to require that everyone > > use an EAI-capable account and user agent. Even if you could get IETF > > participants to do that - and I can assure you that pigs will fly first - > > think about the added cost of participation that brings. > I think 'everyone' may be difficult, but something like 99% or 99.9% > will eventually happen, just because for most kinds of software, it's > easier to produce one version for use worldwide than to uselessly divide > the market. > As for added cost of participation, upgrading something like gmail is > essentially instantaneous and free, and upgrading something like > Thunderbird requires only a click or two. As these types of applications > these days form the bulk of MUAs, the overall/average costs for > participation won't be too big. If you actually think there's no cost to "upgrading" your mail provider, changing the client you use, or even adding an additional provider and client to your workflow, there's no point in further discussion. Ned From nobody Tue Oct 18 01:52:30 2016 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B85921299C7 for ; Tue, 18 Oct 2016 01:52:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gVjCnLeGtP_y for ; Tue, 18 Oct 2016 01:52:26 -0700 (PDT) Received: from JPN01-OS2-obe.outbound.protection.outlook.com (mail-os2jpn01on0106.outbound.protection.outlook.com [104.47.92.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D66DE1299C2 for ; Tue, 18 Oct 2016 01:52:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector1-it-aoyama-ac-jp; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=mA1/zn6ZAeVQL0lwS4bsfWX+bAKwp3fuzSO+YMJItRc=; b=cKMt+zGLwDqynlraManUCekdNWbs4YzZ/+FW4Cd3gl028tencTt3zPVT7rXi9mvfSxtGt5OdyfoMaXjNF1w0UY06aOfTkDGqGYyVLDSL9q1Lwla/Q8yEMm0L9B8GEAFqzaC0Dy/f04IB+veqj65mS9cjy9HMhqNJyQYumnXQs8E= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=duerst@it.aoyama.ac.jp; Received: from [133.2.210.64] (133.2.210.64) by TYXPR0101MB0992.jpnprd01.prod.outlook.com (10.168.45.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.659.11; Tue, 18 Oct 2016 08:52:22 +0000 To: Ned Freed References: <776420919.20161016132653@uanic.net> <01Q66PLXP7X800Q5OH@mauve.mrochek.com> <2f03e34f-36b3-4d9f-44b3-de21d008cfc6@it.aoyama.ac.jp> <01Q684KWD5D200Q5OH@mauve.mrochek.com> From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <93ede69d-1b5a-74d6-feb8-6f8f78ef79bb@it.aoyama.ac.jp> Date: Tue, 18 Oct 2016 17:52:21 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <01Q684KWD5D200Q5OH@mauve.mrochek.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [133.2.210.64] X-ClientProxiedBy: OS2PR01CA0023.jpnprd01.prod.outlook.com (10.161.74.161) To TYXPR0101MB0992.jpnprd01.prod.outlook.com (10.168.45.147) X-MS-Office365-Filtering-Correlation-Id: 6f656069-00dd-4a53-431a-08d3f734138e X-Microsoft-Exchange-Diagnostics: 1; TYXPR0101MB0992; 2:Av6MaADEN7hlxFvVqH61IanPMGYh0HOUsiOjYZofx+iRP0hD6/Nob1KreMzrKzY5vHNT97swHG2s5GtsozlgIwhNIZ5lGkgQnYrudWP0ssRPO0EBhODg7mbsKpdDLsE+ORV3314SVDx2r3ghYIRPespSYrqVUhpqjHQBBP/ekamYfVaNo1oTWbXMyo8/IzVna7xUv8ACGJRRqKhrUxqAKg==; 3:81Po6ovnaV/kNezBZ4rEpoC0m67n7W+jIYKj0SG8fQ/SME7HU6fuejewHXH3UP6d06Q/1wGg45U3Xweu6AJDxWLqRyxh+RJ1X+Hi0stnSKBg2F8lUzZU8cXDy0tPXsBJvHpvbOJ3gEsGy4k+2No25g==; 25:uuIFAIpHteCt77zu1QM33mimCStA4Dhcd2WG2+3orG7xBD6L44NKnsDHSYkS5fqswGsmZ4xMPthw3ooEjun22/WjWDmf7SHLKcohDaQUKGQ5xnCG0jRLGj0yIW3H3KbzO+TNi3WaTNhJ6o8vd1FEmfQw3Wg/MCQ1f/3XsxWZMELa5+azG5GuuWp5JeVJolwk9HB/teLbSvZg8CfETxp6E6zrFOTYfiakM2gkbueNBIMHmyUXIhy77/fBWRR2B83qj8+/ZntvxsZS4Ej0oBrTIBA7yrgVD40rY2iRMFOhbxlNjbZRrQexRpDAi2X90K4AUP9IR4sqzvbUfVGaRPvtTIywngAVWZXokZDrdYlrB9IhIZCYRyeLEu7o3+uuc8UzLdK5IhLrYeqE1RhVT5K/4JhQQf5zuO/ikOAUAPv+/OnKxfl07+3t8OxV+UWmDM+o X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:TYXPR0101MB0992; X-Microsoft-Exchange-Diagnostics: 1; TYXPR0101MB0992; 31:QqQiLPze2ecaMo4k/XnhiIrVY7TpRSgk870do4vjnHEtShpl4rshrUlKlLb3g3W6FxseR0EIphzWmSXwC94WNCnOf2P4Eo+6bhANnNhd4XNxA9AX9n0ZlOCaNWOnwkqjh/9DB96Eqg1gc0I99cUL+ACIdxBNZPgybYvaEwk8+APwPyCM+Gfqd30uncXcjHi9759asDHz+tNMpykFiFcF8NmiuPVQRcS/ygL1EVLMXi4aIoeVCBRgJnzZMlWRp/hc; 4:y+hMJxszLPRCOMcE01TeGEAKcLk5j8qcKyiqf/oGkECBDq5Ac0bQ17uRteLdKHqd+1L1T5dmliXdVgY0jxLw5QdO1eAfXFnRGT7h9RQ2Wc57WT+C3KBbir+snwmCsnT8NSSyi0/Ap3KcFL2TSs33tBr2AQGLSbxXWqBToHlBuq+9KHsHEBtXmxQBCDuHGQUakI8g5guHZlX8h8Oe1kPyIdBe9aEvGLxJmk+yapLN6yBqbhbPAjw3FNxPWg/FGVKfHm0IoAjO6Yj3uISlxlHpD4ygkv2v0C1sqELJTnqCdKV6dXpseWixiqC91kEMfTvblIZBGIuM9LN3xLdAdGaAL/qcFn8iv5/PSL7YjY3gI8iEyOSlVKfQuptwUt7sRMScIAfneV0u4JX8xaSPfhVgdIBk1H9HgxAb4KALI0NMf3hx4rBhNjxYrsk0KY0xTGMGFoTGlNxNtuhUAvAvSH02tZJASW5+Wqu2XLW/afmHjKSv0fJ45dRVhTDODs2Pchrg X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(278428928389397)(271806183753584); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6043046)(6042046); SRVR:TYXPR0101MB0992; BCL:0; PCL:0; RULEID:; SRVR:TYXPR0101MB0992; X-Forefront-PRVS: 00997889E7 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(7916002)(189002)(24454002)(199003)(93886004)(65826007)(189998001)(5660300001)(3846002)(586003)(230700001)(50466002)(101416001)(6916009)(6116002)(64126003)(74482002)(33646002)(83506001)(65956001)(81156014)(2906002)(4326007)(77096005)(66066001)(65806001)(97736004)(105586002)(106356001)(68736007)(4001350100001)(42186005)(2950100002)(305945005)(31686004)(47776003)(110136003)(81166006)(42882006)(8676002)(31696002)(86362001)(23676002)(50986999)(76176999)(54356999)(92566002)(8666005)(7846002)(7736002)(3940600001); DIR:OUT; SFP:1102; SCL:1; SRVR:TYXPR0101MB0992; H:[133.2.210.64]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: it.aoyama.ac.jp does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtUWVhQUjAxMDFNQjA5OTI7MjM6TE43cTdTNVhwQ0hSKzBESWRGRnU4aEhL?= =?utf-8?B?azJnNWtLT3l3UDd0NTVPOHJyTGEvR1JGK2M3UW1hQythZUVBWDVZeEpVcnoy?= =?utf-8?B?WW9UNkZTV29Qb0lKUllzWTUvSitJbjlZUGphOXNpUHFOblpzaUc0cTNucjZv?= =?utf-8?B?alpJbm1QdVFTWmkxZ1lsYjMrazhoSld2UjdIWGM2UmRIMUVGNmovQ29pV0dy?= =?utf-8?B?djRVMlEyeDV1ZmVDYW9veVBlWlMwTzJBNmYyTzArd0MycjJTdUdMRU1SNEw5?= =?utf-8?B?S1QxbEUrWWpjWXRWZEs3c2tSd05FNFk5d2ZpNkVxVSs0dUhVeENVZ3RsVU5l?= =?utf-8?B?a2lBSkxQekcvaHZFajAwcFhtUnJsZVAyYXNkNFVkR1lKTW9ObTNIYk51dHZv?= =?utf-8?B?SkVKWGNFSUZGcGVpL080N2w4Wk8wd0lDazhSRDQxQzBRR0l1SWREY3pGTTZl?= =?utf-8?B?d1ErUHpnVU5lM1ZFUVhUMXNUOFJKaFViVHdCNjl5RG5nWGVERU1xT0RURmk0?= =?utf-8?B?bmUydjczdERjdTBUeTErdWlFWnBVVXRxQ1RMVm5kcXRJVGhIR0htQ2N6QytB?= =?utf-8?B?L25oZUttUzIyL3BzeEp1Zkc2cE9XLzJ5YndyTW0zK3ZJb25MWUoyeEJHU2lU?= =?utf-8?B?ZWFEdmZHcnpSV2hiTGJsVHdZamZCaTNUQ1ZlRlNtME5GMi92bWNNTEJmNEVM?= =?utf-8?B?S2I1azE3N0FLalBvdlhMTVhuVGZMK09xRnVPZXhCRnpFYzVpQm9iQUY2NVZB?= =?utf-8?B?YnVYY1kyejdkU1dmY2hlVVhUeG1YbkZmem9UWHNKNmFlMWx1QzU3eTE0VTU3?= =?utf-8?B?elZPOUNPQ2NnZEg5UmRPVFJrditoWXJTcW1qNEZtQTZEdnYrNUJwS1ZrRzRk?= =?utf-8?B?YjRJUkUzYk9jOTZmYWkvdEM4NWFJMGZBVk0zY2h4djRYeERPQ0lzcW9FRTJG?= =?utf-8?B?Qms3bWdqdWZJeXBtWW9tUit2cDdTYUNMdERQRFN1VVYvMytDdW1HelEwUnRj?= =?utf-8?B?dUljeXgwUmQrMHFrWWtUYXQrUHo3TTFOOTVtMlNBZktYZ3QxV216bHQ3aG9Z?= =?utf-8?B?c0ZvR0VJUEVLdnU0c3Bwc3g3WDdsOXJWcE81bnZZcm04a09udElMR2ZZdXgx?= =?utf-8?B?UW9ITkdya3A2Ty95eStMV1NnQysyaHlOdFNaVWhtOEhRMHcyaThqZE5zVlcy?= =?utf-8?B?WlNla1I0a2dEbk5DeGplcXNlbFo2ZS93Wmx4VWc0ZGFQeHJYZWZ4dUNKRFZo?= =?utf-8?B?M2l2T2pSTzBTYk92ZlUrTkdwYXhOL08vM1cwRVhtNHlaaWtwSFRXcXJ2dTZy?= =?utf-8?B?WUNDTk5UR0d5NlE2eCtqanpiMytjN0FKZ3N3YkozbndGcVV6RWEyeTNyUi9C?= =?utf-8?B?a3B3UFVUVmoxNWVJN2Y2QXczM0doWFZ1WHpDSjNMYnQrS2J4Qm5LemRpT3dy?= =?utf-8?B?bDZwT2czWEsxalVMVm5YT1NOY0NnNGpKdGhvekx3Uk5qbFcrd3pSNE9yVkVS?= =?utf-8?B?VnNwOTlzdGY2dno4WExYQ1BNbHZrMkRNcm0zZTV3d3l1bEN6NHF3TWxZT25y?= =?utf-8?B?SGlLMFdTaWoyNWxwaUQ2UW8rNXUvRDIvamxoTlQ0SFNRMGR4emtFRE1DbUIr?= =?utf-8?B?eS9Rbk5wb1JRVjJmaGdSbG9YcUZ3T0tGZ0RwbXQ4L1RncTRCV3E3NGQ3ZUxT?= =?utf-8?B?YzRnWnR4NVBXaVNCcjAzbkdSa2lYbnpRK2NYRVErY2ZUY2xUOFlVM0RxM1VW?= =?utf-8?Q?aU6JCG7wFpqNDXoqMwnv/tyXlf9Tkr8Kt50qY6s=3D?= X-Microsoft-Exchange-Diagnostics: 1; TYXPR0101MB0992; 6:lG64d4eBBEOjuRwEnHa3oPJ36lSf7Qf6k0DyKrolq7LlrnFi23suTy6b/DP7DU9LzhFez1qD1hTHyTzt3IZHbihUItNVEwXFePjCUdtiGaE/Ef5t864oTE0tJvP2cB4zu1oODPJJMEtmcsAiK94/Q2wLPaHVENXSdYL9LDzQNHqbWCuP5qehDvcRaAunsJCwC7MtdXSWhV1IVEiegHqfJzyqwE7iDVLktTo6saEuS0ImjbZKUE8/jj3/MBAmDv1DCRMJO4yMcTzx33s4C1EN5Ue6kN38P9x5neiPk/mEmtyMIe0oskvqtBdsZhtTJD2k8m/MeD33y1vQEd2tz1aVRA==; 5:AhnM7Qc/WpkUyyXp6pDxY+q/Q3uDeJk0hlo+ou6k0BppK4jaqKNBUQNb/FOwU5xD5yhHZNntGyAXl4H0zWUL3UUrG6mJeC4mlSJcb7abTMK7vyuafDFc7WWT3GD9cV/nw1bWm6gLMOXtN+0cfuq+cw==; 24:QIxffVZjL5H5cofRr1tr/ApfpgWu2Myz+CrQ1k0Gyf1ieYkbhaXpWAc5XyHamEfasUs18z91rtKsuh3nIB7mHsh7H89O/0+QJrDSL8doTf0= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; TYXPR0101MB0992; 7:ae3eLdKj5UGzfCylkrvAugERZIY5HTbkrTr2urwoSyQXLDjl8lYN1zDHzmWeLyytDuuxIHHst8x+i8oacWW9tbpJJyojh55MuG09SXJi68fA+zBjycioJBeEh4Dql418LXi4loI8WKp1H2+Ie2cfxragxyE0GNAjQ0CECpZG5+ctW+g2FfEzLwgrbKV0Jelr7Kl4zYjARtVhyuBBlTBVSNVEI2A15AcVBWlfMrvebSbham++tAKRSY9VUYNFDo2I5M78FgNHzIDKVY/RKf0MF2yYwd2R2Bux/I2v30VzRIWV3weu/UjGK+EsmyX6AvVwDF3lJEJATe2f0SeRhUDHJSg1OphhMQ9oLTgvLuBZk5Q= X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Oct 2016 08:52:22.5960 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYXPR0101MB0992 Archived-At: Cc: Shawn Steele , "ima@ietf.org" Subject: Re: [EAI] [IETF] Content Issues [ X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 08:52:29 -0000 Hello Ned, On 2016/10/18 07:17, Ned Freed wrote: >> Hello Ned, >> I think 'everyone' may be difficult, but something like 99% or 99.9% >> will eventually happen, just because for most kinds of software, it's >> easier to produce one version for use worldwide than to uselessly divide >> the market. > >> As for added cost of participation, upgrading something like gmail is >> essentially instantaneous and free, and upgrading something like >> Thunderbird requires only a click or two. As these types of applications >> these days form the bulk of MUAs, the overall/average costs for >> participation won't be too big. > > If you actually think there's no cost to "upgrading" your mail provider, > changing the client you use, or even adding an additional provider and > client > to your workflow, there's no point in further discussion. I'm sorry, but I never said (nor intended to say) that changing your mail provider or the client you use, or adding one more of one or both of these, is easy or cheap. What I tried to say is that for *most* participants, at *some point in time*, the upgrade will essentially be free and simple. Regards, Martin. From nobody Tue Oct 18 09:11:09 2016 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A59B12958C for ; Tue, 18 Oct 2016 09:11:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1OqzqYs46VmB for ; Tue, 18 Oct 2016 09:11:06 -0700 (PDT) Received: from nm2-vm5.bullet.mail.ne1.yahoo.com (nm2-vm5.bullet.mail.ne1.yahoo.com [98.138.91.224]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6B46129487 for ; Tue, 18 Oct 2016 09:11:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1476807066; bh=G+yw8aDCGeULEKZm/bCgpb3OGj1BpwhCPVCruPhzak8=; h=Date:From:Reply-To:To:Cc:Subject:References:From:Subject; b=tarBU8JWSJB8PvyGyBfdVbb9BmtrxJFLYQSki3XvP9dzjba+zBgmxP6HEK1x/9MQwnWvmwNQWgyeJgslFVqaaGPm59jUNxluIVX12duvdVFK72j1OVxlzyPP71EFwKlNBuKkQrXnh7Ughh5XRBYTI0sPCm9Nk8ezKyVw9DKDjnJnMZj/bm9AF3aoHcrmGGizvaLgQESDRNT4s4vefCUQYj+pnJJ3O40xhygu4PRlPo1ygwTa3A30JMs7QBllExzqAFMTo19z7tuIqXzXpDdu31brfiITQhEmqHv0GBNyPogJ3YYgSmI0UCwVWGe8wnySrCOx4vvcagLMR2qJol6ixw== Received: from [98.138.226.177] by nm2.bullet.mail.ne1.yahoo.com with NNFMP; 18 Oct 2016 16:11:06 -0000 Received: from [98.138.89.248] by tm12.bullet.mail.ne1.yahoo.com with NNFMP; 18 Oct 2016 16:11:06 -0000 Received: from [127.0.0.1] by omp1040.mail.ne1.yahoo.com with NNFMP; 18 Oct 2016 16:11:06 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 173339.27547.bm@omp1040.mail.ne1.yahoo.com X-YMail-OSG: 6QksF1oVM1kWiBFlzUK.vpwfCz60fz2v7f_8cvzrowv7dqghK6iNzpN7QvGVG6a iK3G_Pci_bGLz4WFKY6ycdNZT1McsztH40HBfibzMJfK88ondH2NA7J9fgZlwUOvlP3AyndEA1i. zw8nesI3cCq4uid4PI5QhqGxVGhzuhxh6bQIlE_UjVO4evoXw.Uz3TSRSDe08Bw8jmHdjK1GPiZ1 RfrLizaU1pR8U_ekTZYByITQ47ibjuQB17Sa_Kb..qjCQEInmbsmCH0VTWTzftv72mqEduhYkKyD HOgQz66UJYtARc2H.q294ziu16jNPqwrqkUoI.1E3RWN8EPCGvICWNifo1gaCcNkxm7xfjt3kmyL 7mRhFbvJvG3pazomMFRuCRB1OdVCaXcPax8B4CynQj6LAFOOy1OAieS2Mck6xV_LLji.OIhMkspU j5_7SlCXnD6GxsHcf6iSz6ZkxE.TCcEYzmrBJcZL_0RS6jBnvEr55za6kumt0wfvR0Whbu7sR06s Wesbn3BhR_JXY75VNoWPIV9h9vI8_CALPsTqRcgxg0uI8wf2RnejBPrVQncHVWaYdwZiPVYXDbU0 sL.xvS7fS Received: from jws200091.mail.ne1.yahoo.com by sendmailws137.mail.ne1.yahoo.com; Tue, 18 Oct 2016 16:11:05 +0000; 1476807065.729 Date: Tue, 18 Oct 2016 16:11:03 +0000 (UTC) From: To: "ima@ietf.org" Message-ID: <555822971.2148272.1476807063013@mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit References: <555822971.2148272.1476807063013.ref@mail.yahoo.com> Archived-At: Cc: Harish Chowdhary Subject: [EAI] Discussion in Seoul of Deployment Challenges / Barriers to IDN - IEA X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: nalini.elkins@insidethestack.com List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 16:11:08 -0000 All, We have discussed this at the tail end of some emails, but I wanted to start a fresh one so that it is relatively clean. We wanted to have a discussion in Seoul of Deployment Challenges / Barriers to IDN - IEA so that we could start documenting them and building a core group to carry on with this work. I also wonder if a document that may be needed is a "Use Cases of Email Addresses". As has been discussed, email addresses are used as "identities" in a number of instances. For shopping, government, email lists, etc. We may want to discuss this. If we have a breakfast meeting at 8:00am Korea time on Thursday, November 17, it looks like that will be 6:00pm EST in the U.S. So, I think some of the people in the U.S. could participate. Are there other time zones that we should be taking into account for remote access? Please let me know if you are interested in participating in this discussion either live or remotely & then I will go forth to try to get us a room. Replying to me unicast is just fine or on the list. Whichever you prefer. Thanks, Nalini Elkins Inside Products, Inc. www.insidethestack.com (831) 659-8360 From nobody Tue Oct 18 17:27:11 2016 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E6E512943A for ; Tue, 18 Oct 2016 17:27:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.131 X-Spam-Level: X-Spam-Status: No, score=-3.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id STUoAlRxvEpN for ; Tue, 18 Oct 2016 17:27:07 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8314C129535 for ; Tue, 18 Oct 2016 17:27:07 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id d132so12583043oib.2 for ; Tue, 18 Oct 2016 17:27:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bNCoWVIJo8jAJyXOapJQJvzHjllIsCxog+veGA0T4Po=; b=mla+NYl6TAr/I65GwVEktgmWB65/xss3JwioSw3GhkCxVIlxN7i+o0jG6NTq87Cq9t 91vMK2LUo0hqg6LWHQh+XQwYq9UgXWT7N9ktK5CdlRMGP+aVyxclfMe3iGndJNDlaca3 Gv9vD2KU/NJIM2QbS1MtLPFt9uYN0C7x7EoNVuA4HSNaJ1SgPIUTLSii4cW8FtXMd4kv 2ktwbxlkgIq9ihU/3qcigvByEA2wZyNZnjgE4/M24ZuEgLZVXiUnRPnv/YoKhBS13wNL nsgGqQpHGIvhaBIH4c2tOsNT5scpDk0JdhEnxsEQNDy5cg5S8OCeLLZpouC8g6tEA48Y PR9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bNCoWVIJo8jAJyXOapJQJvzHjllIsCxog+veGA0T4Po=; b=Q/HVJazjBepOJYBc1BWlzJHeUvSobP0hr0VgZX2aLY6fIcv21S1MP9EA9/Jr48nleC 1JE4S1aeTy7QGYdMWti6dYzsJQZ5PHp2lKbjaqLaRniWWdCPquAZMcB624ckYn5gWfId HhaihPcMV78/ZqzvNieUjYR8IDqDmDi68aTv17r0Wm1PceysT8QLWqzSnl8mlyW1sUNL kw4p1iPe2TKInhZm4LxymmjtdpusT2whbVXRtp+3kunHB+EXM6jcBxLvpxZrPz/bd6lE qevv7T0A9s+bd5ZIlTAC/xZjKialy8Q0C/ut8hglyrsdJKYu7QpR9zh79l72pfAh8I60 V6DA== X-Gm-Message-State: AA6/9RmLN5UKFOuAAQ6dz5xxyxKxOBlYd90we8fypXKwz5JtldjDsGvc12e2sfB+baRwfN5vOKWuTlbShn8Lmycg X-Received: by 10.202.241.136 with SMTP id p130mr2637369oih.186.1476836826709; Tue, 18 Oct 2016 17:27:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.58.213 with HTTP; Tue, 18 Oct 2016 17:27:06 -0700 (PDT) In-Reply-To: <2048473830.314096.1476457637592@mail.yahoo.com> References: <20161006055447.32573.qmail@pro-236-157.rediffmailpro.com> <9EC0EB65-9C58-43ED-9A80-1DA32C58E3E0@att.com> <2048473830.314096.1476457637592@mail.yahoo.com> From: John Bucy Date: Tue, 18 Oct 2016 17:27:06 -0700 Message-ID: To: nalini.elkins@insidethestack.com Content-Type: multipart/alternative; boundary=94eb2c09415672dcdb053f2cde8a Archived-At: Cc: Harish Chowdhary , John C Klensin , "ima@ietf.org" Subject: Re: [EAI] [IETF] Multiple Addresses [ was: Internationalized Email Internet Draft] X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2016 00:27:09 -0000 --94eb2c09415672dcdb053f2cde8a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On Fri, Oct 14, 2016 at 8:07 AM, wrote: > John / Tony, > > >(4) Multiple addresses for one user (and Section 4). Keeping in mind > that many people maintain a number of identities, and even multiple email > addresses, for different purposes, I >don't understand what point you are > trying to make with this section. > > Sure. People have multiple email addresses for different reasons. The > question was actually with aliases. Maybe it is not possible to have all > email consolidated to one box. > > For example, if I want to have two mailboxes: > > nalini@mymailserver.com and नलिनी@mymailserver.com (or > नलिनी@[myidnserver].[myinternationaltld]) all come to one mailbox is that > possible? Should it be possible? > > I *think* people want that. I think we will know as this all takes off. > > > >Many of us believe that users who have mailboxes whose names involve > non-ASCII local parts and who engage in communications outside their > primary language group will find it >necessary to maintain either separate > all-ASCII mailboxes or all-ASCII aliases to their primary mailboxes and to > do so for a very long time. > While we don't have concrete product plans at this time, it is my expectation that Gmail will support adding on an eai alias to an existing account long before we will support creating a Google Account with a non-ascii primary username. This might look similar to the existing "custom from" feature. cheers john --94eb2c09415672dcdb053f2cde8a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On Fri, Oct 14, 2016 at 8:07 AM, <nalini.elkins@insidethestack.com> wrote:
John / Tony,

>(4) Multiple addresses for one user (and Section 4).  Keeping in mind that many people maintain a number of identities, and even multiple email addresses, for different purposes, I >don't understand what point you are trying to make with this section. 

Sure.  People have multiple email addresses for different reasons.   The question was actually with aliases.  Maybe it is not possible to have all email consolidated to one box.

For example, if I want to have two mailboxes:

nalini@mymailserver.com and नलिनी@mymailserver.com (or नलिनी@[myidnserver].[myinternationaltld]) all come to one mailbox is that possible?   Should it be possible?

I *think* people want that.   I think we will know as this all takes off.


>Many of us believe that users who have mailboxes whose names involve non-ASCII local parts and who engage in communications outside their primary language group will find it >necessary to maintain either separate all-ASCII mailboxes or all-ASCII aliases to their primary mailboxes and to do so for a very long time.

While we don't have concrete product plans at this time, it is my expectation that Gmail will support adding on an eai alias to an existing account long before we will support creating a Google Account with a non-ascii primary username. This might look similar to the existing "custom from" feature.



cheers
john

--94eb2c09415672dcdb053f2cde8a-- From xn--74q5c021c@xn--blq510jgwa.xn--55qx5d Fri Oct 14 09:56:22 2016 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3454C127A91 for ; Fri, 14 Oct 2016 09:56:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.293 X-Spam-Level: X-Spam-Status: No, score=0.293 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c8PjvjOrDi58 for ; Fri, 14 Oct 2016 09:56:12 -0700 (PDT) Received: from e-mailtech.net (unknown [120.31.129.134]) by ietfa.amsl.com (Postfix) with ESMTP id 49876127077 for ; Fri, 14 Oct 2016 09:56:10 -0700 (PDT) Received: by ajax-webmail-cnnic.icoremail.net (Coremail) ; Sat, 15 Oct 2016 00:55:13 +0800 (GMT+08:00) X-CM-HeaderCharset: UTF-8 X-Originating-IP: [216.52.21.0] Date: Sat, 15 Oct 2016 00:55:13 +0800 (GMT+08:00) From: "Franck Martin" To: ima@ietf.org X-Priority: 3 X-Mailer: Coremail Webmail Server Version XTO_3.6.0_2015.10 dev build 20151103(76851.8158) Copyright (c) 2002-2016 www.mailtech.cn zh X-SendMailWithSms: false Content-Type: multipart/alternative; boundary="----=_Part_713_2007556578.1476464113724" MIME-Version: 1.0 Message-ID: <6bd33b71.8f.157c41e784a.Coremail.___@___.__> X-CM-TRANSID: AQAAfwBXxjryDQFYdo8BAA--.82W X-CM-SenderInfo: 10qnglkutvuiesrfq5bqnnuzbtvriyhjzdh5zqnnkkdt0vv/1tbiA QAHEVPBRXcAMQABsH X-Coremail-Antispam: 1Ur529EdanIXcx71UUUUU7IcSsGvfJ3iIAIbVAYjsxI4VW5Jw CS07vEb4IE77IF4wCS07vE1I0E4x80FVAKz4kxMIAIbVAFxVCaYxvI4VCIwcAKzIAtYxBI daVFxhVjvjDU= Archived-At: X-Mailman-Approved-At: Tue, 18 Oct 2016 18:26:19 -0700 Subject: [EAI] How to deal with EAI X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 18:20:38 -0000 ------=_Part_713_2007556578.1476464113724 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 VGhpcyBlbWFpbCBpcyBsaWtlbHkgdG8gZW5kIHVwIGluIHRoZSBtb2RlcmF0b3IgcXVldWUsIGJ1 dCBpZiBJIGNhbm5vdCBzdWJzY3JpYmUsIG1heSBiZSBJIGNhbiBwb3N0Pwo= ------=_Part_713_2007556578.1476464113724 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 VGhpcyBlbWFpbCBpcyBsaWtlbHkgdG8gZW5kIHVwIGluIHRoZSBtb2RlcmF0b3IgcXVldWUsIGJ1 dCBpZiBJIGNhbm5vdCBzdWJzY3JpYmUsIG1heSBiZSBJIGNhbiBwb3N0Pzxicj4= ------=_Part_713_2007556578.1476464113724-- From nobody Tue Oct 18 19:03:03 2016 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2D97129521 for ; Tue, 18 Oct 2016 19:03:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sqCTI4u1OZNb for ; Tue, 18 Oct 2016 19:03:00 -0700 (PDT) Received: from nm20-vm0.bullet.mail.ne1.yahoo.com (nm20-vm0.bullet.mail.ne1.yahoo.com [98.138.91.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FDA6129517 for ; Tue, 18 Oct 2016 19:03:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1476842579; bh=RSm1zQN+oY6oF16t3DLtPSz9ILWpeMns3pvez4KRGeg=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=G8T0Q6WaHBdLLFUtCg/xYUHq8T+VqGYyx0u6foog8rFzMx7r2yn6KY+Jq8Hjke2Ofh9jwBZL/X3SJfmR4iH11Aaw8JgAcu5LRgT/2lKfMu+kFJKTrUhwOh/81jkNQR2G6WncGeC7Nqtm4hSQr/BM+ILIgm6Ysc1iygKOaOWCldgYtIvJaqvc+8LYQUjaVbt1XqDA94+tfncnd9HaEDFO0qH5nAe+oqSCxR6ZHOx4hZ01hwq3jHElTbmEZEnDqxxWHmiC40OYk2FLGbBYwPcEbmnbgBsRmYvpRkF8iP+9xpZWWmZfGkSUQdv8+axXuv8vOhd8zxMVLVmexynE5i7cMA== Received: from [98.138.100.114] by nm20.bullet.mail.ne1.yahoo.com with NNFMP; 19 Oct 2016 02:02:59 -0000 Received: from [98.138.89.240] by tm105.bullet.mail.ne1.yahoo.com with NNFMP; 19 Oct 2016 02:02:59 -0000 Received: from [127.0.0.1] by omp1013.mail.ne1.yahoo.com with NNFMP; 19 Oct 2016 02:02:59 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 470253.65775.bm@omp1013.mail.ne1.yahoo.com X-YMail-OSG: RIDwvfAVM1mrud3aDezxoVAGgNRm7fk2YaWkOJSa._p6am3AAYpmpSfGAwTOrUx OgKfjlPXkURRAvCDT4EywLH1lFooR04Z2l0kcGpc9zpgcvF4_fbGgfXD71WjLMoNUuLPGlw4mn8q psvojl7kR_f5P8uWxS5kXvgV3mj6pO1H9WuAeeHNck1M7Bvd2eVx2K2r9zYuXnu4y4psdp3hlwaO nzsV.pKATZKIZrZzLvKtD8r4.nFoOA_W9dgpPc0zlTc9thiEWuZyMqrAnNx0jUu1TdBowShlXPDa sVKXOOrdWdYFJWQsQOfL0s_Kgkt0umW46njTHFrdyVAEA_bh_2SPffZjGycfPSlIbGxS6BlmIQUM Cp5WDlgVT7X6YhMJccLVD74pp3BePB2cqm9nNHMJQkTj8XAlJ5bLh1t8pW1JeTNJ.R0FmriAggDr G2f2k7r5_S7mLfvcSXBiX28uvG.XZpTM2FliQTugr66FujAL54geNwLMVCC9agIDsDzBKt4pDWFU ZYOy9.XOhxH7UfBYqHm_WD_jHy7G81ZEWaBtqMLrpVC0y16DEORaQFs38MPNrKpcL8lKfY0v3jL7 YtLYh1pwa Received: from jws200018.mail.ne1.yahoo.com by sendmailws127.mail.ne1.yahoo.com; Wed, 19 Oct 2016 02:02:59 +0000; 1476842579.049 Date: Wed, 19 Oct 2016 02:02:58 +0000 (UTC) From: To: "ima@ietf.org" Message-ID: <1054227051.941475.1476842578566@mail.yahoo.com> In-Reply-To: <6bd33b71.8f.157c41e784a.Coremail.___@___.__> References: <6bd33b71.8f.157c41e784a.Coremail.___@___.__> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_941474_1459111045.1476842578562" Archived-At: Subject: [EAI] Fw: How to deal with EAI X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: nalini.elkins@insidethestack.com List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2016 02:03:02 -0000 ------=_Part_941474_1459111045.1476842578562 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Franck, I actually got your email in my REGULAR email & not spam! But, the local part of your email address is showing in punycode. =C2=A0I b= elieve that is "against the rules". =C2=A0 Am I wrong on that? BTW, I was not able to do a REPLYALL, so I am forwarding the email.=C2=A0Th= anks, Nalini ElkinsInside Products, Inc.www.insidethestack.com(831) 659-8360 =20 ----- Forwarded Message ----- From: Franck Martin To: ima@ietf.org=20 Sent: Friday, October 14, 2016 9:55 AM Subject: [EAI] How to deal with EAI =20 This email is likely to end up in the moderator queue, but if I cannot subs= cribe, may be I can post? _______________________________________________ IMA mailing list IMA@ietf.org https://www.ietf.org/mailman/listinfo/ima =20 ------=_Part_941474_1459111045.1476842578562 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Franck,

= I actually got your email in my REGULAR email & not spam!

But, the local part of your email address is show= ing in punycode.  I believe that is "against the rules".   Am I w= rong on that?

BTW, I was not able to = do a REPLYALL, so I am forwarding the email.
 
Tha= nks,

Nalini Elkins
Inside Products, Inc.
=
www.insidethestack.com
(831) 659-8360



----- Forwarded Message -----
From: Franck Martin <xn--74q5c021c@=E4=BA= =92=E8=81=94=E7=BD=91.=E5=85=AC=E5=8F=B8>
To: ima@ietf.org
Sent: Friday, October 14, 2016 9:55 AM
Subject: [EAI] How to deal with EAI
=

This email is likely to end u= p in the moderator queue, but if I cannot subscribe, may be I can post?
=

_______________________________________________
IMA mailing li= st
IMA@ietf.org
https://www.ietf.org/mailman/listinfo/ima
<= br>
------=_Part_941474_1459111045.1476842578562-- From nobody Tue Oct 18 19:04:39 2016 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF7E7129517 for ; Tue, 18 Oct 2016 19:04:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 51luFLJCl8Sd for ; Tue, 18 Oct 2016 19:04:36 -0700 (PDT) Received: from nm2-vm6.bullet.mail.ne1.yahoo.com (nm2-vm6.bullet.mail.ne1.yahoo.com [98.138.91.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDA39129650 for ; Tue, 18 Oct 2016 19:04:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1476842675; bh=Ney3Tj7L+Q3DsPCebllFESauSia9sDWbyDpUj6kxBDM=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=ccSiHcY5StO9RA2TWL0lZ983wg5lMU4e2Xz3pJAfLxKciaCo0pwUxi9eWHqp8kmmAgUXHA9tIq7MAR4RbUGqbA/KPZdfukhSEB7uF9xW6IKJ1VKCli1tox5jIS+gAKPE8us7crH+DToLDDboEzW8VEf6zdJ5lsqBREclqikmErMuuISaq1KhM6QtKLhxu8jAyuN549hqwzxvHZTwu6ZTdYA4ja981RnBsa6pTsLMmFDrtiQsdbI1l1P2+Z/WW4/SnORn8ANMt+5WaTX+nyHvR5ceAp7dVuT+zv08DRspb/QJjQZmktlPmOL41NymCHWplEnHEnjYzvNTUTr1uFSI6w== Received: from [98.138.226.178] by nm2.bullet.mail.ne1.yahoo.com with NNFMP; 19 Oct 2016 02:04:35 -0000 Received: from [98.138.88.238] by tm13.bullet.mail.ne1.yahoo.com with NNFMP; 19 Oct 2016 02:04:35 -0000 Received: from [127.0.0.1] by omp1038.mail.ne1.yahoo.com with NNFMP; 19 Oct 2016 02:04:35 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 357253.67131.bm@omp1038.mail.ne1.yahoo.com X-YMail-OSG: H0yCToYVM1kcNqJTY.qzsCDPADldTPwbV6tfsQjQ3tBQukaQ.Pm16IJwPGYxXum PaVJeaX.N9baJZbiPvXlqaTcmyiXpcWEHAq09gJ_8WyITMfxSYOZZpEuK.ZlKqFu6puSsNX1t.XE 2C_y8ZJTCDzXexnjEePl8PJRjkrdl_Fd0XqDZvM0mVen8viK9AnLa4H0k1dwQEYzyTf20x6Eo40I cR7u4khSrDmbfsOqb9oqvBOoDr3U9DGrs4UAGoVL95fUxeITjyiU8M6za3k0P1irac7Lij2sSOqX ff__WpE00Q1VpmggT7HG_zLPUC1sGVf74qY.v3CXzmcNlti_bxE60lT8ftEPLrSP1eKVkEDfeMme pcBjKoSxZQLZoFQ30fYMXShgBg49VXX2BdwQcQ_NuUQKpEO2EfF5DuMIKKmdoXkl6EJJmiV0Yex3 q74hJ35R0PLGfZLTuje7EuAKsPP659HK1Q1ATDulJ5wvWKhEpJQBpGnu_hjOWS3ZK1hvl_7peWVX sIotcxbs2W_BIBkx3l.e1cmvqiCd5QTrEo64MmjWOKLtnUnyycz6T49qtS7GnLYOH34rgFmrL2Q-- Received: from jws200186.mail.ne1.yahoo.com by sendmailws150.mail.ne1.yahoo.com; Wed, 19 Oct 2016 02:04:34 +0000; 1476842674.962 Date: Wed, 19 Oct 2016 02:04:34 +0000 (UTC) From: To: John Bucy Message-ID: <1867082512.2570178.1476842674408@mail.yahoo.com> In-Reply-To: References: <20161006055447.32573.qmail@pro-236-157.rediffmailpro.com> <9EC0EB65-9C58-43ED-9A80-1DA32C58E3E0@att.com> <2048473830.314096.1476457637592@mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2570177_389639462.1476842674402" Archived-At: Cc: Harish Chowdhary , John C Klensin , "ima@ietf.org" Subject: Re: [EAI] [IETF] Multiple Addresses [ was: Internationalized Email Internet Draft] X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: nalini.elkins@insidethestack.com List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2016 02:04:38 -0000 ------=_Part_2570177_389639462.1476842674402 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable John, =20 On Fri, Oct 14, 2016 at 8:07 AM, wrote: John / Tony, >(4) Multiple addresses for one user (and Section 4).=C2=A0 Keeping in=C2= =A0mind that many people maintain a number of identities, and even=C2=A0mul= tiple email addresses, for different purposes, I >don't=C2=A0understand wha= t point you are trying to make with this section.=C2=A0 Sure.=C2=A0 People have multiple email addresses for different reasons. =C2= =A0 The question was actually with aliases.=C2=A0 Maybe it is not possible = to have all email consolidated to one box. For example, if I want to have two mailboxes: nalini@mymailserver.com and=C2=A0=E0=A4=A8=E0=A4=B2=E0=A4=BF=E0=A4=A8=E0=A5= =80@mymailserver.com (or=C2=A0=E0=A4=A8=E0=A4=B2=E0=A4=BF=E0=A4=A8=E0=A5=80= @[myidnserver].[myint ernationaltld]) all come to one mailbox is that possi= ble? =C2=A0 Should it be possible? I *think* people want that. =C2=A0 I think we will know as this all takes o= ff. >Many of us believe that users who have mailboxes whose names involve non-A= SCII local parts and who engage in communications outside their primary lan= guage group will find it >necessary to maintain either separate all-ASCII m= ailboxes or all-ASCII aliases to their primary mailboxes and to do so for a= very long time. >While we don't have concrete product plans at this time, it is my expectat= ion that Gmail will support adding on an eai alias to an existing account l= ong before we will support creating a >Google Account with a non-ascii prim= ary username. This might look similar to the existing "custom from" feature= . Great! =C2=A0 Definitely a start! If you would like to test out the alias feature, please let us know. =C2=A0= We will be happy to help. Nalini =20 ------=_Part_2570177_389639462.1476842674402 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
John,

<= div style=3D"font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, = Lucida Grande, sans-serif; font-size: 16px;" id=3D"yui_3_16_0_ym19_1_147684= 2267913_8232">
=

On Fri, Oct 14, 2016 at 8:07 AM, <nalini.elkins@insidethestack. com> wrote:
=
John / Tony,=

>(4= ) Multiple addresses for one user (and Section 4).  Keeping in mi= nd that many people maintain a number of identities, and even multiple= email addresses, for different purposes, I >don't understand what = point you are trying to make with this section. 

Sure= .  People have multiple email addresses for different reasons.   = The question was actually with aliases.  Maybe it is not possible to = have all email consolidated to one box.

For example, if I want to have two mailboxes:

<= a rel=3D"nofollow" shape=3D"rect" ymailto=3D"mailto:nalini@mymailserver.com= " target=3D"_blank" href=3D"mailto:nalini@mymailserver.com">nalini@mymailse= rver.com and =E0=A4=A8=E0=A4=B2=E0=A4=BF=E0=A4=A8=E0=A5=80= @mymailserver.com (or =E0=A4=A8=E0=A4=B2=E0=A4= =BF=E0=A4=A8=E0=A5=80@[myidnserver].[myint ernationaltld]) all come to one = mailbox is that possible?   Should it be possible?
<= br clear=3D"none">
<= span style=3D"font-family:HelveticaNeue-Light,;">I *think* people want that= .   I think we will know as this all takes off.


>Many of us believe that users w= ho have mailboxes whose names involve non-ASCII local parts and who engage = in communications outside their primary language group will find it >nec= essary to maintain either separate all-ASCII mailboxes or all-ASCII aliases= to their primary mailboxes and to do so for a very long time.
<= /div>

>While we don'= t have concrete product plans at this time, it is my expectation that Gmail= will support adding on an eai alias to an existing account long before we = will support creating a >Google Account with a non-ascii primary usernam= e. This might look similar to the existing "custom from" feature.


Great!   Definitely a s= tart!

If you would like to test out the al= ias feature, please let us know.   We will be happy to help.

Nalini


------=_Part_2570177_389639462.1476842674402-- From nobody Tue Oct 18 19:47:42 2016 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA6331296C0 for ; Tue, 18 Oct 2016 19:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.752 X-Spam-Level: X-Spam-Status: No, score=-4.752 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=linkedin.com header.b=yiQXcnob; dkim=pass (1024-bit key) header.d=linkedin.com header.b=bS+/iI5M Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ht7MVJ-Oeoka for ; Tue, 18 Oct 2016 19:47:39 -0700 (PDT) Received: from mail522.linkedin.com (mail522.linkedin.com [108.174.6.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3473E1296A7 for ; Tue, 18 Oct 2016 19:47:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; s=proddkim1024; t=1476845247; bh=9SKsJp3d/i+TZxcn/CjauSdALcIwxp8hiBIaF5S7aZo=; h=MIME-Version:From:Date:Subject:To:Content-Type; b=yiQXcnobEEc+d54nd1CFdTVso7mmhDylvwFK3YtWmAJbSeyf40nH9wdzSB4+UlY3+ 9yQcO5Uix16LtR/CvHkAKkOF/DNxkO3ae1KTGYZRT1agVp7FtpFzlc0wSnWJRU82ji lyN7v0OjH6VESjTS67y9tHuifRv0VoIb25LU9oec= Authentication-Results: mail522.prod.linkedin.com x-tls.subject="/C=US/ST=California/L=Mountain View/O=Google Inc/CN=smtp.gmail.com"; auth=pass (cipher=ECDHE-RSA-AES128-GCM-SHA256) Authentication-Results: mail522.prod.linkedin.com; iprev=pass policy.iprev="2607:f8b0:400c:c05::248"; spf=softfail smtp.mailfrom="fmartin@linkedin.com" smtp.helo="mail-vk0-x248.google.com"; dkim=pass header.d=linkedin.com; tls=pass (verified) key.ciphersuite="TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256" key.length="128" tls.v="tlsv1.2" cert.client="C=US,ST=California,L=Mountain View,O=Google Inc,CN=smtp.gmail.com" cert.clientissuer="C=US,O=Google Inc,CN=Google Internet Authority G2" Received: from [2607:f8b0:400c:c05::248] ([2607:f8b0:400c:c05::248.35556] helo=mail-vk0-x248.google.com) by mail522.prod.linkedin.com (envelope-from ) (ecelerity 3.6.21.53563 r(Core:3.6.21.0)) with ESMTPS (cipher=ECDHE-RSA-AES128-GCM-SHA256 subject="/C=US/ST=California/L=Mountain View/O=Google Inc/CN=smtp.gmail.com") id 34/DE-11653-FBED6085; Wed, 19 Oct 2016 02:47:27 +0000 Received: by mail-vk0-x248.google.com with SMTP id 2so12019076vkb.2 for ; Tue, 18 Oct 2016 19:47:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9SKsJp3d/i+TZxcn/CjauSdALcIwxp8hiBIaF5S7aZo=; b=bS+/iI5MJO7hFpceG647zT/caSxp+mdn+VhdyZkAXJJRJMDqkhmCm/zeli+V0lva1O l4UQkJp1RMZ2ZWq/4ZNlgLcp5oUDuGdbTM1cUrfTTYlzbchmuF/+s/57Ig1Bm0V0FuJ+ QYeFDIILNL1N2jX/OF40yV75ekpsKH5W/txKo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9SKsJp3d/i+TZxcn/CjauSdALcIwxp8hiBIaF5S7aZo=; b=QPsxBEAcFUYEcofsuHZZ1Zd0zNjWQiLXDEnoHDz3wfzoIkJJzpOE8OceqN8mjsbQVi Tz2PUCfY0bl1COCvgZTRX/t/SBSgEHXogUB5pUvsmnI9BxHHCAy16qYEjMJPh+Fx6C2r W6Rdfamfj03t3Oxa0NaoFqF9+5LW73Gi7DTr8rGxVjq6qv6lFKvJWAui0PV0b72+IN+Z ZuVRyHVeHKXSBlOTq9ZsjtF74zEp+V4LYpDCNXFufODuWfTCBxtX3Hx0MYGcbtXa9o1e /bW452bBBH84FMrz9Rs6pv8kidhyAaAlwLEg3E/v5wts3G1N+i/w+SSLFM5E+bTZDX7M 1F6w== X-Gm-Message-State: AA6/9RlVV54t8/GBXuW1gefvkofUcFiKARPYFOIWyo9iCYUjION9jzTibIKjS0v3l0J5clHWiW/4whluFKL8Zl9KqXBM+/GIu6ou+b2MeGlZgy3N9oqWGIcKk42mNHPYOiLaVs8CIpNtR+YovwwievOiDQ== X-Received: by 10.176.69.195 with SMTP id u61mr707384uau.37.1476845246884; Tue, 18 Oct 2016 19:47:26 -0700 (PDT) X-Received: by 10.176.69.195 with SMTP id u61mr707363uau.37.1476845246445; Tue, 18 Oct 2016 19:47:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.49.22 with HTTP; Tue, 18 Oct 2016 19:47:05 -0700 (PDT) In-Reply-To: <1054227051.941475.1476842578566@mail.yahoo.com> References: <6bd33b71.8f.157c41e784a.Coremail.___@___.__> <1054227051.941475.1476842578566@mail.yahoo.com> From: Franck Martin Date: Tue, 18 Oct 2016 19:47:05 -0700 Message-ID: To: Nalini Elkins Content-Type: multipart/alternative; boundary=94eb2c11be5c4da22a053f2ed435 Archived-At: Cc: "ima@ietf.org" Subject: Re: [EAI] Fw: How to deal with EAI X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2016 02:47:42 -0000 --94eb2c11be5c4da22a053f2ed435 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The coremail system uses an aliasing mechanism to transform the local part into puny code. There is no rule about what can be an alias of an email address, so it is not against the rules, but cannot be a standard and should not be a standard. It works for them because the character set (Chinese one) is restricted to one that can be puny coded. I'm curious why you could not reply to all? On Tue, Oct 18, 2016 at 7:02 PM, wrote: > Franck, > > I actually got your email in my REGULAR email & not spam! > > But, the local part of your email address is showing in punycode. I > believe that is "against the rules". Am I wrong on that? > > BTW, I was not able to do a REPLYALL, so I am forwarding the email. > > Thanks, > > Nalini Elkins > Inside Products, Inc. > www.insidethestack.com > (831) 659-8360 > > > > ----- Forwarded Message ----- > *From:* Franck Martin > *To:* ima@ietf.org > *Sent:* Friday, October 14, 2016 9:55 AM > *Subject:* [EAI] How to deal with EAI > > This email is likely to end up in the moderator queue, but if I cannot > subscribe, may be I can post? > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima > > > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima > > --94eb2c11be5c4da22a053f2ed435 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The coremail system uses an aliasing mechanism to transfor= m the local part into puny code. There is no rule about what can be an alia= s of an email address, so it is not against the rules, but cannot be a stan= dard and should not be a standard. It works for them because the character = set (Chinese one) is restricted to one that can be puny coded.

I'm curious why you could not reply to all?

On Tue, Oct 18, 2016 at 7:= 02 PM, <nalini.elkins@insidethestack.com> wr= ote:
Franck,

=
I actually got your email in my REGULAR email & not spam!

But, th= e local part of your email address is showing in punycode.=C2=A0 I believe = that is "against the rules". =C2=A0 Am I wrong on that?

BTW,= I was not able to do a REPLYALL, so I am forwarding the email.
<= /div>
= =C2=A0
Thanks,

<= /div>
Nalini Elkins
Inside Products, Inc.


=
----- Forwarded Message -----
= From: Franck Martin <xn--74q= 5c021c@=E4=BA=92=E8=81=94=E7=BD=91.=E5=85=AC=E5=8F=B8>
To: ima@ietf.org
Sent= : Friday, October 14, 2016 9:55 AM
Subject: [EAI] How to deal with EAI

This email is likely= to end up in the moderator queue, but if I cannot subscribe, may be I can = post?

_______________________________________= ________
IMA mailing list
IMA= @ietf.org
https://www.ietf.org/mailman/listinfo/ima


=

_________________________________= ______________
IMA mailing list
IMA@ietf.org
https://www.ietf.org/mailman/listinfo/ima


--94eb2c11be5c4da22a053f2ed435-- From nobody Wed Oct 19 06:25:20 2016 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A74812957A for ; Wed, 19 Oct 2016 06:25:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.331 X-Spam-Level: X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BXD9ry-oFT_C for ; Wed, 19 Oct 2016 06:25:17 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91C3512962E for ; Wed, 19 Oct 2016 06:25:17 -0700 (PDT) Received: from [198.252.137.10] (helo=JcK-HP8200) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1bwqrr-0009w1-GP; Wed, 19 Oct 2016 09:25:15 -0400 Date: Wed, 19 Oct 2016 09:25:10 -0400 From: John C Klensin To: nalini.elkins@insidethestack.com Message-ID: <233FFBEC11DE530E61CE3254@JcK-HP8200> In-Reply-To: <2048473830.314096.1476457637592@mail.yahoo.com> References: <20161006055447.32573.qmail@pro-236-157.rediffmailpro.com> <9EC0EB65-9C58-43ED-9A80-1DA32C58E3E0@att.com> <2048473830.314096.1476457637592@mail.yahoo.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: Harish Chowdhary , ima@ietf.org Subject: Re: [EAI] [IETF] Multiple Addresses [ was: Internationalized Email Internet Draft] X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2016 13:25:19 -0000 --On Friday, October 14, 2016 15:07 +0000 nalini.elkins@insidethestack.com wrote: >... >> (4) Multiple addresses for one user (and Section 4).=C2=A0 >> Keeping in=C2=A0mind that many people maintain a number of >> identities, and even=C2=A0multiple email addresses, for = different >> purposes, I >don't=C2=A0understand what point you are trying = to >> make with this section.=C2=A0 > Sure. =C2=A0People have multiple email addresses for different > reasons. =C2=A0 The question was actually with aliases. = =C2=A0Maybe it > is not possible to have all email consolidated to one box. For > example, if I want to have two mailboxes: > nalini@mymailserver.com = and=C2=A0=E0=A4=A8=E0=A4=B2=E0=A4=BF=E0=A4=A8=E0=A5=80@mymailserv= er.com > = (or=C2=A0=E0=A4=A8=E0=A4=B2=E0=A4=BF=E0=A4=A8=E0=A5=80@[myidnserv= er].[myinternationaltld]) all > come to one mailbox is that possible? =C2=A0 Should it be = possible? > I *think* people want that. =C2=A0 I think we will know as = this > all takes off. One more comment on this. I'm encouraged by John Bucy's comment that Gmail will support this and I hope the other large providers will too. However, to put your question in perspective, ability to create aliases for mailbox names has been common in Internet email systems (and supported by every publicly-available one I have encountered) for a very long time. >From the perspective of the SMTP specs, even having upper and lower case ASCII match in the local-part is an aliasing issue, not a fundamental requirement or transformation. Expanding an otherwise well-designed and "8 bit clean" mail delivery system and server to treat an incoming non-ASCII local-part as an alias for an all-ASCII one should be simply a matter of modifying the server to accept non-ASCII local parts and then disabling any internal syntax checks that prohibit such addresses. The harder problems lie elsewhere. If the server for example.com accepts Joe.bLogs@example.com and an alias for, and equivalent to, joe.bloggs@example.com, whether Joe's MUA and submission servers will allow sending from the former address form is a matter for those servers, not the mailbox name or delivery systems. Some will, some won't. Similarly, there are a few different ways to handle aliases in terms of what, if anything, is done to the message headers. One can imagine a number of interesting issues in IMAP / POP interfaces or in receiving MUAs and that number increases when non-ASCII addresses are added in. > Can you point me to some of that work?=20 In (non-IETF) tutorials about Internet email and documents for specific systems, yes. Other than a comment here and there (with case sensitively as a good example), the IETF standards have deliberated avoided these issues because handling of mailbox names and aliases are considered to be purely local matters. best, john