From nobody Wed Apr 15 02:13:33 2015 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50B721B33A4 for ; Wed, 15 Apr 2015 02:13:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 6xX3qY8M-31g for ; Wed, 15 Apr 2015 02:13:29 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E4381B32E2 for ; Wed, 15 Apr 2015 02:13:29 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 669D8FA0038; Wed, 15 Apr 2015 09:13:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1429089207; bh=cesGNQ4Y1axwD+20qOUGRpOakGul5RdV77eFxX4EsGs=; h=From:To:Subject:Date:From; b=bMszfK9VVyOLD0MmJzdWqf98B4FW2Bb/uohGVssUs6iUOM/piLOK5hB7GRPeK6dar OIXwzIVR//E/SVBWlPHVAHMedwah1bPfLHbD16lHK009ROExt4hMzCB7ztemxTB28Y t4kcmRT7I5R2EVwHbGX+n1dJoog+zgAbyz3REKMA= Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1429089206-31136-31135/12/1001; Wed, 15 Apr 2015 09:13:26 +0000 From: Arnt Gulbrandsen To: ima@ietf.org Date: Wed, 15 Apr 2015 11:13:26 +0200 User-Agent: Trojita/v0.5-9-g8961725; Qt/4.8.6; X11; Linux; Ubuntu 14.04.2 LTS Mime-Version: 1.0 Message-Id: <0b1ef499-c45c-4f20-97e9-550363572060@gulbrandsen.priv.no> Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: Subject: [EAI] FWIW, draft-ietf-dane-openpgpkey-03 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2015 09:13:32 -0000 Some of you might want to take an interest in that. Might. My wife pointed me to it, I've glanced at it and a) it seems to copy 4255, which AFAICT hasn't been much of a success and b) it adds to PGP, ditto. I can't find any motivation to care. But perhaps one of you should, so it'll avoid gratuitous incompatibility with 6530. Arnt From nobody Wed Apr 15 02:24:32 2015 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B7251B33C0 for ; Wed, 15 Apr 2015 02:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.688 X-Spam-Level: X-Spam-Status: No, score=0.688 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 rWcHvv8Tawdi for ; Wed, 15 Apr 2015 02:24:30 -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 6D9051B33C4 for ; Wed, 15 Apr 2015 02:24:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; s=proddkim1024; t=1429089867; bh=RqNGk/Uh99z9/DfNs9w3suq0G3fXuGvgxNrRyfyLZCo=; h=From:To:Subject:Date:Content-Type:MIME-Version; b=qdSVXtRviqXxgkkPauiLwfMIWXvOddeqPvhUktKi/nWH0tDRiIUjTuM8uf7z1FUor TWd9kN/cInpE0ElEFFA5l+22kZrhkyTj/NjvUZzBGOTSy6aO9+LSBdm8Ia1NHCBwWq I6gtDqxuVSm8Bq8L2OqVawhtXGXF/rNG3oCmg+jY= Authentication-Results: mail522.prod x-tls.subject="/C=US/ST=California/L=Mountain View/O=LinkedIn Corporation/CN=*.corp.linkedin.com"; auth=pass (cipher=RC4-SHA) Received: from [172.18.129.50] ([172.18.129.50:42464] helo=eat1-mav01.corp.linkedin.com) by mail522.prod (envelope-from ) (ecelerity 3.6.7.46655 r(Core:3.6.7.0)) with ESMTPS (cipher=RC4-SHA subject="/C=US/ST=California/L=Mountain View/O=LinkedIn Corporation/CN=*.corp.linkedin.com") id 60/A3-17681-B4E2E255; Wed, 15 Apr 2015 09:24:27 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1429089867; x=1460625867; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=RqNGk/Uh99z9/DfNs9w3suq0G3fXuGvgxNrRyfyLZCo=; b=HibY1Kpd6MMW+zw+wHk9EhmY2jflxmUeOS7QQT03NwYgZRGm1XS5nnRC 2P/BlB4cRTyyP44mT11oxC7yKgpsX4MCZxKsL/56us63ESRQerX9HXuGr QKC8GR60RdmIBlOjaavcJmvHu3y+qmWUqFYwwy4QR6k41khdfa/6p7JQ1 s=; X-IronPort-AV: E=Sophos;i="5.11,581,1422950400"; d="scan'208";a="4588817" Received: from LVA1-MB01.linkedin.biz ([fe80::9ca6:542a:3dc7:d0fd]) by LVA1-HUB02.linkedin.biz ([::1]) with mapi id 14.03.0195.001; Wed, 15 Apr 2015 02:24:27 -0700 From: Franck Martin To: ima Thread-Topic: SMTPUTF8 and 8BITMIME Thread-Index: AQHQd133ZFi2gGl62kC6RN+BKpLDPw== Date: Wed, 15 Apr 2015 09:24:25 +0000 Message-ID: <3D9223A5-135E-4F43-B814-EB7BE51D207C@linkedin.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.36.245] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [EAI] SMTPUTF8 and 8BITMIME X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2015 09:24:31 -0000 aXQgc2VlbXMgdGhhdCBhIGZldyBNVEEgY2FuIGJlIHRocm93biBhdCBhbiBlbWFpbCB3aXRoIGEg RUFJIFJGQzUzMjEubWFpbGZyb20gYW5kIHBhc3MgdGhlIG1lc3NhZ2UgZmluZSB0byBvdGhlciBN VEEgb3IgbG9jYWwgZGVsaXZlcnksIGFzIGxvbmcgYXMgdGhlIE1UQSBzdXBwb3J0cyA4QklUTUlN RSBhbmQgdGhlIFJGQzUzMjEucmNwdHRvIGlzIGEgc3RhbmRhcmQgZW1haWwgYWRkcmVzcy4gDQoN CnJlcGx5aW5nIHRvIHN1Y2ggZW1haWwgaXMgYSBjaGFsbGVuZ2UsIGJ1dCBpdCBkb2VzIG5vdCBz ZWVtIGFueSBNVEEgb3IgTVVBICh3aXRoIDhCSVRNSU1FKSB3aWxsIGNvbXBsYWluIGJlY2F1c2Ug dGhlIFJGQzUzMjEuZnJvbSBpcyBhbiBFQUkuLi4NCg0KV2hhdOKAmXMgeW91ciBleHBlcmllbmNl Pw== From nobody Wed Apr 15 07:42:51 2015 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1B1F1B35C0 for ; Wed, 15 Apr 2015 07:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 2BF_QUQAf1NW for ; Wed, 15 Apr 2015 07:42:47 -0700 (PDT) Received: from mail.ijs.si (mail.ijs.si [IPv6:2001:1470:ff80::25]) (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 863431B35BE for ; Wed, 15 Apr 2015 07:42:47 -0700 (PDT) Received: from amavis-proxy-ori.ijs.si (localhost [IPv6:::1]) by mail.ijs.si (Postfix) with ESMTP id 3lRmcj15J9z3B; Wed, 15 Apr 2015 16:42:45 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ijs.si; h= user-agent:message-id:references:in-reply-to:organization :subject:subject:from:from:date:date:content-transfer-encoding :content-type:content-type:mime-version:received:received :received:received; s=jakla4; t=1429108959; x=1431700960; bh=KeF 07KYsSAZZ5pxHc8CrCMb3I9431hsvzKMQOuasaMM=; b=ZSzJsD30qkLTX0gyYhE zPMV7GbCpUOC5OMy3qBPgsmc7gDmzMzHVaWCxE/aR0ilcNgAaEzVR/Z6uGsgHtGE A2iluyCqmsAmvudmdeSUbJKQtVtFG8jWZ1uXRJp3zxTK1qoJkCPF4pyB0fV9yjQq T7DnFcTtRxhU2Z9cKBnlBCPs= X-Virus-Scanned: amavisd-new at ijs.si Received: from mail.ijs.si ([IPv6:::1]) by amavis-proxy-ori.ijs.si (mail.ijs.si [IPv6:::1]) (amavisd-new, port 10012) with ESMTP id uem7JikoHkL0; Wed, 15 Apr 2015 16:42:39 +0200 (CEST) Received: from mildred.ijs.si (mailbox.ijs.si [IPv6:2001:1470:ff80::143:1]) by mail.ijs.si (Postfix) with ESMTP; Wed, 15 Apr 2015 16:42:38 +0200 (CEST) Received: from neli.ijs.si (neli.ijs.si [IPv6:2001:1470:ff80:88:21c:c0ff:feb1:8c91]) by mildred.ijs.si (Postfix) with ESMTP id 3lRmcZ4p9qz1Ps; Wed, 15 Apr 2015 16:42:38 +0200 (CEST) Received: from neli.ijs.si ([2001:1470:ff80:88:21c:c0ff:feb1:8c91]) by neli.ijs.si with HTTP (HTTP/1.1 POST); Wed, 15 Apr 2015 16:42:38 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Date: Wed, 15 Apr 2015 16:42:38 +0200 From: Mark Martinec To: Franck Martin Organization: Jozef Stefan Institute In-Reply-To: <3D9223A5-135E-4F43-B814-EB7BE51D207C@linkedin.com> References: <3D9223A5-135E-4F43-B814-EB7BE51D207C@linkedin.com> Message-ID: <954498e8f424c243f5d1f25ec535f365@mailbox.ijs.si> X-Sender: Mark.Martinec+ietf@ijs.si User-Agent: Roundcube Webmail/1.1.1 Archived-At: Cc: ima Subject: Re: [EAI] SMTPUTF8 and 8BITMIME X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2015 14:42:51 -0000 2015-04-15 11:24, Franck Martin wrote: > it seems that a few MTA can be thrown at an email with a EAI > RFC5321.mailfrom and pass the message fine to other MTA or local > delivery, as long as the MTA supports 8BITMIME and the RFC5321.rcptto > is a standard email address. >=20 > replying to such email is a challenge, but it does not seem any MTA or > MUA (with 8BITMIME) will complain because the RFC5321.from is an > EAI... >=20 > What=E2=80=99s your experience? Tried it with Postfix (with SMTPUTF8 disabled): it gladly accepts UTF-8 in localpart of a RFC5321.mailfrom (or in the RFC5321.rcptto) address, as well as UTF-8 in a mail header section - but rejects UTF-8 in domain part of such address (501 5.1.7 Bad sender address syntax). =2E.. unfortunately the cyrus LMTP server then rejects the=20 RFC5321.mailfrom (501 5.5.4 Syntax error in parameters) - although it does survive UTF-8 in a mail header section. Mark From nobody Wed Apr 15 08:01:10 2015 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37A651A00D4 for ; Wed, 15 Apr 2015 08:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.612 X-Spam-Level: X-Spam-Status: No, score=-0.612 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 3nDij-lzCabu for ; Wed, 15 Apr 2015 08:01:07 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2231D1A8AF3 for ; Wed, 15 Apr 2015 08:01:06 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PKTYIHZFLC00J2NY@mauve.mrochek.com> for ima@ietf.org; Wed, 15 Apr 2015 07:56:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mrochek.com; s=mauve; t=1429109764; bh=Z49CqIId6aj9J9a3ZAXPSjzXEQ3SBvpStr5oq7O2ARA=; h=From:Cc:Date:Subject:In-reply-to:References:To; b=kiN/y3P15C1CW0WSjXaLBwdnWPZZGlxyfeR5USpac2C2T5W/cf6L/8GIF2RUDIqrs iy0QC68c45W/okOh0BMtNG4+Ax1PAa1Gfl7RsREZhob2ar23MeLSwu0Z9xgYWZfoQU 4EMuOwfar9/cqsoIkyorGS2pgDs50CCLcRJN5JPk= MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: TEXT/PLAIN; charset=utf-8 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PKJBBQ6BO00000AQ@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Wed, 15 Apr 2015 07:56:01 -0700 (PDT) From: ned+ima@mrochek.com Message-id: <01PKTYIGGNDC0000AQ@mauve.mrochek.com> Date: Wed, 15 Apr 2015 07:50:19 -0700 (PDT) In-reply-to: "Your message dated Wed, 15 Apr 2015 09:24:25 +0000" <3D9223A5-135E-4F43-B814-EB7BE51D207C@linkedin.com> References: <3D9223A5-135E-4F43-B814-EB7BE51D207C@linkedin.com> To: Franck Martin Archived-At: Cc: ima Subject: Re: [EAI] SMTPUTF8 and 8BITMIME X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2015 15:01:08 -0000 > it seems that a few MTA can be thrown at an email with a EAI RFC5321.mailfrom > and pass the message fine to other MTA or local delivery, as long as the MTA > supports 8BITMIME and the RFC5321.rcptto is a standard email address. > replying to such email is a challenge, but it does not seem any MTA or MUA > (with 8BITMIME) will complain because the RFC5321.from is an EAI... > What’s your experience? Depending on the version and configuration, the Oracle MTA will either accept such a MAIL FROM address but sanitize the 8bit, or reject it outright. RCPT TOs containing 8bit are always rejected. Ned From nobody Tue Apr 21 06:07:23 2015 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80F691A03A5 for ; Tue, 21 Apr 2015 06:07:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.699 X-Spam-Level: X-Spam-Status: No, score=0.699 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 5zRY0Fh6xsXM for ; Tue, 21 Apr 2015 06:07:16 -0700 (PDT) Received: from st15.mi6.kiev.ua (st15.mi6.kiev.ua [91.198.36.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B71711A039F for ; Tue, 21 Apr 2015 06:07:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=i.ua; s=mail; h=Message-Id:Content-Transfer-Encoding:Content-Type:References:MIME-Version:Date:In-Reply-To:Cc:From:Subject:To; bh=Ib+GPxS1oxM6V9mDaDUt9W40Epr4D4NGo6S30pc1Ikw=; b=jd60kCngOriT5nEXkpMSQAxxCoIN2+D69zzVR4mroJ1DjIkkJ2CZtPF9b30fxgYFRo03pxGU0/Jx12WS/5DlfJGAVcrPt+bNyTdmCzz7TjXvCkqn8oCc+lBzIinGY+M5Be9m3SbsOo0XxtDyLaXBYdbxHbYJ3TvQtp4ckyK2/ck=; Received: from st06.mi6 ([10.0.0.31] helo=st06.mi6.kiev.ua) by st15.mi6.kiev.ua with esmtp (Exim 4.80.1) (envelope-from ) id 1YkXtF-0000To-5J; Tue, 21 Apr 2015 16:07:01 +0300 Received: from web by st06.mi6.kiev.ua with local (Exim 4.80.1) (envelope-from ) id 1YkXtF-0002DH-0s; Tue, 21 Apr 2015 16:07:01 +0300 To: ima@ietf.org From: Oleksandr Tsaruk In-Reply-To: <01PKTYIGGNDC0000AQ@mauve.mrochek.com> Date: Tue, 21 Apr 2015 16:07:01 +0300 MIME-Version: 1.0 References: <3D9223A5-135E-4F43-B814-EB7BE51D207C@linkedin.com> <01PKTYIGGNDC0000AQ@mauve.mrochek.com> X-Mailer: I.UA Mail System X-Server: st06.mi6.kiev.ua X-Sender-IP: 193.19.152.14 (192.168.40.33) X-User-Agent: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.90 Safari/537.36 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Message-Id: Archived-At: Cc: cyrillicgp@icann.org Subject: [EAI] UTF32 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2015 13:07:22 -0000 Is it possible to reconsider (in a very long run) EAI WG general approach to: “This working group's previous experimental efforts investigated the use of UTF-32 as a general approach to email internationalization.” In such case email/domaine internationalization problem could be solved in original scripts? Charter for Working Group "The email address has two parts, local part and domain part. Email address internationalization must deal with both. This working group's previous experimental efforts investigated the use of UTF-8 as a general approach to email internationalization." https://datatracker.ietf.org/wg/eai/charter/ Oleksandr Sincerely yours, Oleksandr Tsaruk, Ph.D. -- реклама ----------------------------------------------------------- Не дорогой качественный хостинг. Приятные сюрпризы для каждого! http://freehost.com.ua/unix/ From nobody Tue Apr 21 07:38:23 2015 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B91EF1AC3D3 for ; Tue, 21 Apr 2015 07:38:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.711 X-Spam-Level: X-Spam-Status: No, score=-0.711 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 aJBzX5HxXGpj for ; Tue, 21 Apr 2015 07:38:21 -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 252761AC3C3 for ; Tue, 21 Apr 2015 07:38:21 -0700 (PDT) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YkZJa-0001aD-9B; Tue, 21 Apr 2015 10:38:18 -0400 Date: Tue, 21 Apr 2015 10:38:13 -0400 From: John C Klensin To: Oleksandr Tsaruk , ima@ietf.org Message-ID: In-Reply-To: References: <3D9223A5-135E-4F43-B814-EB7BE51D207C@linkedin.com> <01PKTYIGGNDC0000AQ@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.35 X-SA-Exim-Mail-From: klensin@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: cyrillicgp@icann.org Subject: Re: [EAI] UTF32 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2015 14:38:22 -0000 --On Tuesday, April 21, 2015 16:07 +0300 Oleksandr Tsaruk wrote: > Is it possible to reconsider (in a very long run) EAI WG > general approach to: > > "This working group's previous experimental efforts > investigated the use of UTF-32 as a general approach to email > internationalization." In such case email/domaine > internationalization problem could be solved in original > scripts? In principle, yes. In practice, given the increasing (and increasingly universal) use of UTF-8 on the wire, probably not. The more important question is what you think going to UTF-32 would accomplish. It is fully isomorphic with UTF-8 -- there is no information that can be represented one way and not the other. It is much less compact than UTF-8 for "western" alphabetic scripts (including Cyrillic), less compact for any BMP code point, and never worse (in terms of more bytes per code point. UTF-32 does not get involved with the "surrogate" mess, but neither does UTF-8. Neither helps at all with the various normalization or comparison problems. The only advantage I can think of at the moment is that UTF-32 permits getting a count of the number of code points present by counting octets and dividing by four while UTF-8 (and UTF-16) require some calculations. However, one rarely cares about number of code points as compared to, e.g., number of "print positions" or "characters" and, given combining sequences and non-spacing characters and marks, getting from a code point count to print position information cannot be done without considerable knowledge of the code points involved (and, for some scripts, rendering procedures). So, can you explain what you think a move to UTF-32, even if it were possible, would accomplish? john From nobody Wed Apr 22 01:07:27 2015 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BBEC1ACDA4 for ; Wed, 22 Apr 2015 01:07:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 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_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 tbb2D0x15sSH for ; Wed, 22 Apr 2015 01:07:25 -0700 (PDT) Received: from mail322.linkedin.com (mail322.linkedin.com [108.174.3.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 71C8D1ACDB3 for ; Wed, 22 Apr 2015 01:07:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; s=proddkim1024; t=1429690043; bh=7Y2KJ5cfU++yvp2hXag2MvpHazEnW/yqe2NP8iiRe5A=; h=From:To:Subject:Date:Content-Type:MIME-Version; b=N0Dc+riLY2pCHLKSljRSYi+EJIgVtBqsyACNrMouC4qEjAcGL8Yb+1Qp3chiQT1PB KxhzUgLJmP0WLTbp6MafbdFWD+c/fp3t0BwXEfaNDyGdSKzpfP6M+98pAxsManqqRY oaHW0Cl/bq7RjqxJjG0JVc8hdnlBUNQuI3c1mJUk= Authentication-Results: mail322.prod x-tls.subject="/C=US/ST=California/L=Mountain View/O=LinkedIn Corporation/CN=*.corp.linkedin.com"; auth=pass (cipher=RC4-SHA) Received: from [172.18.129.51] ([172.18.129.51:21822] helo=eat1-mav02.corp.linkedin.com) by mail322.prod (envelope-from ) (ecelerity 3.6.9.48312 r(Core:3.6.9.0)) with ESMTPS (cipher=RC4-SHA subject="/C=US/ST=California/L=Mountain View/O=LinkedIn Corporation/CN=*.corp.linkedin.com") id FA/90-32663-BB657355; Wed, 22 Apr 2015 08:07:23 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1429690043; x=1461226043; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=7Y2KJ5cfU++yvp2hXag2MvpHazEnW/yqe2NP8iiRe5A=; b=pwYq4cbZzCp86+B/Zyc2H2AxCUVoL8RKu4oEjJ5Epve74M1Py5BsAn8M +e4s6QENeZuR18uSbmFK3ZRgu++NbpuWzYXO5ZEpiJcZIcLThJelwseCC mW5eceKy1FIRB3MEH5a6Bi1V7ITGhODKjWJ3a8hAA/968+gb7lM/FemiQ 8=; X-IronPort-AV: E=Sophos;i="5.11,622,1422950400"; d="asc'?scan'208,217";a="5167926" Received: from LVA1-MB01.linkedin.biz ([fe80::9ca6:542a:3dc7:d0fd]) by LVA1-HUB02.linkedin.biz ([::1]) with mapi id 14.03.0195.001; Wed, 22 Apr 2015 01:07:22 -0700 From: Franck Martin To: yaojk Thread-Topic: [EAI] Chinese email address Thread-Index: AQHQfNNccrxRjfI6yUOU4Ed1u89/7Q== Date: Wed, 22 Apr 2015 08:07:21 +0000 Message-ID: <7C45B427-47E4-4337-A2D2-1275BEA3166F@linkedin.com> References: , <2014122416222946049414@cnnic.cn> <74AB4E55C973F120425B40D4@JcK-HP8200.jck.com>, <1D64B26D-14FE-4376-BAF6-A00DBAD3B2D6@linkedin.com> <2014122509222303016622@cnnic.cn> In-Reply-To: <2014122509222303016622@cnnic.cn> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.29.36.248] Content-Type: multipart/signed; boundary="Apple-Mail=_D7502645-B40F-4045-B329-83ED9E9A5C9F"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 Archived-At: Cc: ima Subject: Re: [EAI] Chinese email address X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 08:07:26 -0000 --Apple-Mail=_D7502645-B40F-4045-B329-83ED9E9A5C9F Content-Type: multipart/alternative; boundary="Apple-Mail=_76215DFA-C88F-4ABE-9512-B3B3B89BADA4" --Apple-Mail=_76215DFA-C88F-4ABE-9512-B3B3B89BADA4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Jiankang, debugging some more... Could you please put an SPF on xn--blq510jgwa.xn--55qx5d Also I notice you require SPF pass to email this domain, otherwise you = get the error: 450 Requested mail action not taken: Invalid IP a 450 is a bit bad, either SPF pass or it does not, SPF temp failures = are rare (but not uncommon) so it should have been a 550. --Apple-Mail=_76215DFA-C88F-4ABE-9512-B3B3B89BADA4 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
Jiankang,

debugging some more...

Could you please put an SPF on xn--blq510jgwa.xn--55qx5d

Also I notice you require SPF pass to email this domain, otherwise you get the error:
450 Requested mail action not taken: Invalid IP

a 450 is a bit bad, either SPF pass or it does not, SPF temp failures are rare (but not uncommon) so it should have been a 550.


--Apple-Mail=_76215DFA-C88F-4ABE-9512-B3B3B89BADA4-- --Apple-Mail=_D7502645-B40F-4045-B329-83ED9E9A5C9F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJVN1a9AAoJEJHd9Bbysc+aqIgH/0MRlCMMC8F+/SROcA5tTCyF JeLtcQCR2kQC41JkVzs1sKBR3EguHCHSc8XwrSK/qKaoquw4WYQpbjOeZxoHyhsk kryLl6dTEhc92z3okpST2r5zK4I+pK879Qk9tPiRydKtL1lVsazDj4496YeIVdLr 2jFhjwvoSLHdTRquaNtWG7tdPooAKHGWnLTmisojYRkVQHSSOdB7MVLzyjXT+iU4 UTJ5Ycx5BByPn1KT41W2PqAAEZNtXamWPW6PapiVaIveEs74hjwXNMftTx6r8kf2 DT7Sufa737oL0Mlu0NpLd93CG+jDvEE5dils0OW2VpgaW7phaq2rLZZn2arTeug= =J6fL -----END PGP SIGNATURE----- --Apple-Mail=_D7502645-B40F-4045-B329-83ED9E9A5C9F-- From nobody Wed Apr 22 05:30:50 2015 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B3961AC3BB for ; Wed, 22 Apr 2015 05:30:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 LXxgkT74XEFW for ; Wed, 22 Apr 2015 05:30:47 -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 32A4B1AC3D4 for ; Wed, 22 Apr 2015 05:30:45 -0700 (PDT) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Yktna-0004zy-H3; Wed, 22 Apr 2015 08:30:38 -0400 Date: Wed, 22 Apr 2015 08:30:33 -0400 From: John C Klensin To: Franck Martin , yaojk Message-ID: In-Reply-To: <7C45B427-47E4-4337-A2D2-1275BEA3166F@linkedin.com> References: , <2014122416222946049414@cnnic.cn> <74AB4E55C973F120425B40D4@JcK-HP8200.jck.com>, <1D64B26D-14FE-4376-BAF6-A00DBAD3B2D6@linkedin.com> <2014122509222303016622@cnnic.cn> <7C45B427-47E4-4337-A2D2-1275BEA3166F@linkedin.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.35 X-SA-Exim-Mail-From: klensin@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: ima Subject: Re: [EAI] Chinese email address X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 12:30:48 -0000 --On Wednesday, April 22, 2015 08:07 +0000 Franck Martin wrote: > Also I notice you require SPF pass to email this domain, > otherwise you get the error: 450 Requested mail action not > taken: Invalid IP > > a 450 is a bit bad, either SPF pass or it does not, SPF temp > failures are rare (but not uncommon) so it should have been a > 550. More generally, you should assume that an SMTP sender will interpret _any_ 4yz code as an indication that it should return the mail to its queue and try again. If such a sender is using the recommended back-off policy for queue management, that will result in several more attempts in the next several hours before backing off toward intervals of multiple hours and keeping that up for days (SMTP requires a minimum of three days). If you can reasonably expect the same message envelope, from the same sender (and address) to be rejected again every time it is tried, then 4yz codes just add extra costs for both the sender and recipient sites. Perhaps more important, it delays any possibility of the sending user getting notification that the message did not go through. john From nobody Wed Apr 22 05:54:55 2015 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A2F51B362D for ; Wed, 22 Apr 2015 05:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.102 X-Spam-Level: X-Spam-Status: No, score=-0.102 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham 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_aB0KDBRL-n for ; Wed, 22 Apr 2015 05:54:51 -0700 (PDT) Received: from st14.mi6.kiev.ua (st14.mi6.kiev.ua [91.198.36.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84E5C1B362E for ; Wed, 22 Apr 2015 05:54:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=i.ua; s=mail; h=Message-Id:Content-Transfer-Encoding:Content-Type:References:MIME-Version:Date:In-Reply-To:Cc:From:Subject:To; bh=BtAQwoGsdRZf8M8sn9rH06d+jY1c9NA16WuY2n25Cu4=; b=MWDqmIrh4614imdFYk6Cddp6J36nL0X/o2Je+zZlsPSQurEmYx5/hcqHbTRZU55zXd43jsJUHrShKl7Gg06811Xerw/wfwMeZCHQmAR4IYCWFAiHoMUkIoaWheltHD7bpyQcCEUXFBPTEg7vux4yhVtpYzrYIgcyzH9nsh72cGM=; Received: from st05.mi6 ([10.0.0.29] helo=st05.mi6.kiev.ua) by st14.mi6.kiev.ua with esmtp (Exim 4.80.1) (envelope-from ) id 1YkuAt-0004ES-1j; Wed, 22 Apr 2015 15:54:43 +0300 Received: from web by st05.mi6.kiev.ua with local (Exim 4.80.1) (envelope-from ) id 1YkuAt-0001Yk-0v; Wed, 22 Apr 2015 15:54:43 +0300 To: John C Klensin From: Oleksandr Tsaruk In-Reply-To: Date: Wed, 22 Apr 2015 15:54:43 +0300 MIME-Version: 1.0 References: <3D9223A5-135E-4F43-B814-EB7BE51D207C@linkedin.com> <01PKTYIGGNDC0000AQ@mauve.mrochek.com> X-Mailer: I.UA Mail System X-Server: st05.mi6.kiev.ua X-Sender-IP: 193.19.152.14 (192.168.40.33) X-User-Agent: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.90 Safari/537.36 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Message-Id: Archived-At: Cc: ima@ietf.org Subject: Re: [EAI] =?utf-8?q?UTF32?= X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 12:54:54 -0000 Dear John Suggestion on UTF32 was about capacity of the table which can handle all known and future developed symbols and hieroglyphs, for case of our days UTF-16 with about 1 million cells could keep all basic symbols of known languages in the Earth. Best Oleksandr 21.04.2015 17:38, John C Klensin >--On Tuesday, April 21, 2015 16:07 +0300 Oleksandr Tsaruk > wrote: > > > Is it possible to reconsider (in a very long run) EAI WG > > general approach to: > > > > "This working group's previous experimental efforts > > investigated the use of UTF-32 as a general approach to email > > internationalization." In such case email/domaine > > internationalization problem could be solved in original > > scripts? > > In principle, yes. In practice, given the increasing (and > increasingly universal) use of UTF-8 on the wire, probably not. > > The more important question is what you think going to UTF-32 > would accomplish. It is fully isomorphic with UTF-8 -- there is > no information that can be represented one way and not the > other. It is much less compact than UTF-8 for "western" > alphabetic scripts (including Cyrillic), less compact for any > BMP code point, and never worse (in terms of more bytes per code > point. UTF-32 does not get involved with the "surrogate" mess, > but neither does UTF-8. Neither helps at all with the various > normalization or comparison problems. The only advantage I can > think of at the moment is that UTF-32 permits getting a count of > the number of code points present by counting octets and > dividing by four while UTF-8 (and UTF-16) require some > calculations. However, one rarely cares about number of code > points as compared to, e.g., number of "print positions" or > "characters" and, given combining sequences and non-spacing > characters and marks, getting from a code point count to print > position information cannot be done without considerable > knowledge of the code points involved (and, for some scripts, > rendering procedures). > > So, can you explain what you think a move to UTF-32, even if it > were possible, would accomplish? > > john Sincerely yours, Oleksandr Tsaruk, Ph.D. -- реклама ----------------------------------------------------------- Не дорогой качественный хостинг. Приятные сюрпризы для каждого! http://freehost.com.ua/unix/ From nobody Wed Apr 22 06:22:00 2015 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA2E11A038E for ; Wed, 22 Apr 2015 06:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 u_aYDtGiIvqg for ; Wed, 22 Apr 2015 06:21:56 -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 A31981A026A for ; Wed, 22 Apr 2015 06:21:55 -0700 (PDT) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YkubC-0005CJ-NZ; Wed, 22 Apr 2015 09:21:54 -0400 Date: Wed, 22 Apr 2015 09:21:49 -0400 From: John C Klensin To: Oleksandr Tsaruk Message-ID: In-Reply-To: References: <3D9223A5-135E-4F43-B814-EB7BE51D207C@linkedin.com> <01PKTYIGGNDC0000AQ@mauve.mrochek.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.35 X-SA-Exim-Mail-From: klensin@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: ima@ietf.org Subject: Re: [EAI] UTF32 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 13:21:59 -0000 --On Wednesday, April 22, 2015 15:54 +0300 Oleksandr Tsaruk wrote: > Dear John >=20 > Suggestion on UTF32 was about capacity of the table which can > handle all known and future developed symbols and hieroglyphs, > for case of our days UTF-16 with about 1 million cells could > keep all basic symbols of known languages in the Earth.=20 Oleksandr, As I suspected, there is probably a misunderstanding somewhere. UTF-32 and UTF-16 are just different encodings for Unicode and can represent exactly the same information. UTF-16 represents code points above U+FFFF by the use of so-called "surrogates". I, personally, dislike surrogates and consider them a kludge, but their availability as part of the UTF-16 system means that UTF-16 can represent anything that UTF-32 can... and so can UTF-8. Now you may be thinking about something else. The Unicode code space ranges only from 0 to 0x10FFFF. A 32bit code space would be 0 to 0xFFFFFFFF. If one believed that the Unicode code space were too small and that a full 32 bit space were needed, that would be a different matter entirely. The Unicode folks are convinced that more than the current space will never be needed to represent all symbols of interest but, at one stage, they believed that a 16bit code space would be enough. I haven't studied the mechanisms in some years, but, if a larger code space were needed, extensions would be needed to both the UTF-8 and UTF-16 encoding models to accommodate it while anything that used a 32 bit space directly would presumably be fairly transparent, at least until one got into various Unicode tables and algorithms that assume the smaller code space. But, again, that has little to do with the difference between UTF-16 and UTF-32 except as a side effect. best, john > 21.04.2015 17:38, John C Klensin >> --On Tuesday, April 21, 2015 16:07 +0300 Oleksandr Tsaruk >> wrote: >>=20 >> > Is it possible to reconsider (in a very long run) EAI WG >> > general approach to: >> >=20 >> > "This working group's previous experimental efforts >> > investigated the use of UTF-32 as a general approach to >> > email internationalization." In such case email/domaine >> > internationalization problem could be solved in original >> > scripts?=20 >>=20 >> In principle, yes. In practice, given the increasing (and >> increasingly universal) use of UTF-8 on the wire, probably >> not. >>=20 >> The more important question is what you think going to UTF-32 >> would accomplish. It is fully isomorphic with UTF-8 -- there >> is no information that can be represented one way and not the >> other. It is much less compact than UTF-8 for "western" >> alphabetic scripts (including Cyrillic), less compact for any >> BMP code point, and never worse (in terms of more bytes per >> code point. UTF-32 does not get involved with the "surrogate" >> mess, but neither does UTF-8. Neither helps at all with the >> various normalization or comparison problems. The only >> advantage I can think of at the moment is that UTF-32 permits >> getting a count of the number of code points present by >> counting octets and dividing by four while UTF-8 (and UTF-16) >> require some calculations. However, one rarely cares about >> number of code points as compared to, e.g., number of "print >> positions" or "characters" and, given combining sequences and >> non-spacing characters and marks, getting from a code point >> count to print position information cannot be done without >> considerable knowledge of the code points involved (and, for >> some scripts, rendering procedures). >>=20 >> So, can you explain what you think a move to UTF-32, even if >> it were possible, would accomplish? >>=20 >> john >=20 >=20 > Sincerely yours,=20 > Oleksandr Tsaruk, Ph.D. >=20 >=20 > -- =D1=80=D0=B5=D0=BA=D0=BB=D0=B0=D0=BC=D0=B0 > ----------------------------------------------------------- > =D0=9D=D0=B5 =D0=B4=D0=BE=D1=80=D0=BE=D0=B3=D0=BE=D0=B9 = =D0=BA=D0=B0=D1=87=D0=B5=D1=81=D1=82=D0=B2=D0=B5=D0=BD=D0=BD=D1=8B= =D0=B9 =D1=85=D0=BE=D1=81=D1=82=D0=B8=D0=BD=D0=B3. > =D0=9F=D1=80=D0=B8=D1=8F=D1=82=D0=BD=D1=8B=D0=B5 = =D1=81=D1=8E=D1=80=D0=BF=D1=80=D0=B8=D0=B7=D1=8B = =D0=B4=D0=BB=D1=8F =D0=BA=D0=B0=D0=B6=D0=B4=D0=BE=D0=B3=D0=BE! > http://freehost.com.ua/unix/ From nobody Wed Apr 22 06:32:47 2015 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1C341A6EDC for ; Wed, 22 Apr 2015 06:32:45 -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 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 vtkdGAGCrgSt for ; Wed, 22 Apr 2015 06:32:39 -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 DD1A61A19FA for ; Wed, 22 Apr 2015 06:32:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx2.yitter.info (Postfix) with ESMTP id 6ADCA10689 for ; Wed, 22 Apr 2015 13:32:11 +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 U5cZBZ0brl5M for ; Wed, 22 Apr 2015 13:32:09 +0000 (UTC) Received: from mx2.yitter.info (c-50-169-68-91.hsd1.nh.comcast.net [50.169.68.91]) by mx2.yitter.info (Postfix) with ESMTPSA id 9D79D10688 for ; Wed, 22 Apr 2015 13:32:09 +0000 (UTC) Date: Wed, 22 Apr 2015 09:32:08 -0400 From: Andrew Sullivan To: ima@ietf.org Message-ID: <20150422133208.GD11774@mx2.yitter.info> References: <3D9223A5-135E-4F43-B814-EB7BE51D207C@linkedin.com> <01PKTYIGGNDC0000AQ@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [EAI] UTF32 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 13:32:45 -0000 On Wed, Apr 22, 2015 at 09:21:49AM -0400, John C Klensin wrote: > Now you may be thinking about something else. The Unicode code > space ranges only from 0 to 0x10FFFF. A 32bit code space would > be 0 to 0xFFFFFFFF. Importantly, if that's the problem one is trying to tackle, there isn't anything the IETF can do about it. It's fully a Unicode issue. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Wed Apr 22 09:10:40 2015 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF5DD1B372C for ; Wed, 22 Apr 2015 09:10:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 xTAeDDWH_PpI for ; Wed, 22 Apr 2015 09:10:35 -0700 (PDT) Received: from mail322.linkedin.com (mail322.linkedin.com [108.174.3.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 BE5D21B36F9 for ; Wed, 22 Apr 2015 09:10:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; s=proddkim1024; t=1429719014; bh=z7+HxG2D4pEb11HgGrSEioQWhafLQuUt/QQhUzpYElk=; h=From:To:Subject:Date:Content-Type:MIME-Version; b=vqV57SC3ud3bDX6MLGaJcWPXWUNPB2u016/Pva6d/Ehx+diuYw1tUeEbDV7uKsd3M brMNGfliWFF65fx2Id3X/M1+RqVu7r3NcMPSXm/oWCh7EmslFDPU48PmkiI4ZHn1q0 8keA4kY/MiwGmnuovA5JPekbW3rbn61J+zbOV4WU= Authentication-Results: mail322.prod x-tls.subject="/C=US/ST=California/L=Mountain View/O=LinkedIn Corporation/CN=*.corp.linkedin.com"; auth=pass (cipher=RC4-SHA) Received: from [172.18.129.50] ([172.18.129.50:13278] helo=eat1-mav01.corp.linkedin.com) by mail322.prod (envelope-from ) (ecelerity 3.6.9.48312 r(Core:3.6.9.0)) with ESMTPS (cipher=RC4-SHA subject="/C=US/ST=California/L=Mountain View/O=LinkedIn Corporation/CN=*.corp.linkedin.com") id D4/83-21297-6E7C7355; Wed, 22 Apr 2015 16:10:14 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1429719014; x=1461255014; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=z7+HxG2D4pEb11HgGrSEioQWhafLQuUt/QQhUzpYElk=; b=Uf9R5chNOFE8jqy+ZEedrB6X+Br2LfS3rCGiwRhaeciL1zobEnITgVHq iUBLXlXZ1xmofCqCX7IIoESRBeYG9O1cEgtO0CR+02e5ad4biXfzf2TxN 97GNsm33ddlnXYbndPI0baPLr3SQb8fiOJi2DSEMQOeZv8GYiUhZNzUSa 8=; X-IronPort-AV: E=Sophos;i="5.11,624,1422950400"; d="scan'208";a="5254288" Received: from LVA1-MB01.linkedin.biz ([fe80::9ca6:542a:3dc7:d0fd]) by LVA1-IHUB01.linkedin.biz ([::1]) with mapi id 14.03.0195.001; Wed, 22 Apr 2015 09:10:13 -0700 From: Franck Martin To: Andrew Sullivan Thread-Topic: [EAI] UTF32 Thread-Index: AQHQfDQfsSNynqhmX062J1A2IpqliJ1X/oeAgAF1aoCAAAeTgIAAAuEA//+20mY= Date: Wed, 22 Apr 2015 16:10:12 +0000 Message-ID: References: <3D9223A5-135E-4F43-B814-EB7BE51D207C@linkedin.com> <01PKTYIGGNDC0000AQ@mauve.mrochek.com> , <20150422133208.GD11774@mx2.yitter.info> In-Reply-To: <20150422133208.GD11774@mx2.yitter.info> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "ima@ietf.org" Subject: Re: [EAI] UTF32 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 16:10:38 -0000 Toute connaissance est une r=E9ponse =E0 une question. > On Apr 22, 2015, at 06:32, Andrew Sullivan wrote= : >=20 >> On Wed, Apr 22, 2015 at 09:21:49AM -0400, John C Klensin wrote: >> Now you may be thinking about something else. The Unicode code >> space ranges only from 0 to 0x10FFFF. A 32bit code space would >> be 0 to 0xFFFFFFFF. >=20 > Importantly, if that's the problem one is trying to tackle, there > isn't anything the IETF can do about it. It's fully a Unicode issue. >=20 Yes, Unicode has a few problems to tackle that is not in the realm of IETF https://modelviewculture.com/pieces/i-can-text-you-a-pile-of-poo-but-i-cant= -write-my-name= From nobody Wed Apr 22 15:41:22 2015 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 477971B3AE2 for ; Wed, 22 Apr 2015 15:41:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.24 X-Spam-Level: *** X-Spam-Status: No, score=3.24 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, MIME_QP_LONG_LINE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 wqWQmhELTWkh for ; Wed, 22 Apr 2015 15:41:19 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 66EEE1B3ACB for ; Wed, 22 Apr 2015 15:41:18 -0700 (PDT) Received: from [192.168.1.110] (unknown [125.33.10.149]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0ApMZWMIzhVnno3AA--.201S2; Thu, 23 Apr 2015 06:41:16 +0800 (CST) References: From: Jiankang Yao Content-Type: multipart/alternative; boundary=Apple-Mail-8FA0CC3B-CBEA-41FA-818C-B9F46A4077A1 X-Mailer: iPhone Mail (11D201) Message-Id: <4B4A1000-1B7F-4D98-981B-1CD3F7666D9E@cnnic.cn> Date: Thu, 23 Apr 2015 06:53:25 +0800 To: ima@ietf.org Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) X-CM-TRANSID: AQAAf0ApMZWMIzhVnno3AA--.201S2 X-Coremail-Antispam: 1UD129KBjvJXoW7Zr4DWrWDGFWkur4UXr1UWrg_yoW8XF1Dpr WkK3y0ga47G3W8K34kZ3W7W3ySvFZ5Ka4Ik34xGw1kAwnxG34YqrWfKw4Fkas3CryUJa1j qF1jvr9rWw4ayrJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUPlb7Iv0xC_KF4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Jr0_JF4l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Jr0_Gr1l84ACjcxK6I8E87Iv67AKxVW8Jr0_Cr1UM28EF7xvwV C2z280aVCY1x0267AKxVW8Jr0_Cr1UM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVAY j202j2C_Xr0_Wr1l5I8CrVAqjxCE14ACF2xKxwAqx4xG64kEw2xG04xIwI0_Jr0_Gr1l5I 8CrVCF0I0E4I0vr24lYx0E2Ix0cI8IcVAFwI0_JrI_JrylYx0Ex4A2jsIE14v26r1j6r4U McvjeVCFs4IE7xkEbVWUJVW8JwACjcxG0xvY0x0EwIxGrwCjr7xvwVCIw2I0I7xG6c02F4 1lc2xSY4AK67AK6Fyl42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1lx2Iq xVAqx4xG67AKxVWUGVWUWwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r 1j6r15MIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY 6xkF7I0E14v26r1j6r4UMIIF0xvE42xK8VAvwI8IcIk0rVWrJr0_WFyUJwCI42IY6I8E87 Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r1j6r4UYxBIdaVFxhVjvjDU0xZF pf9x07jobyZUUUUU= X-CM-SenderInfo: x1dryyw6fq0xffof0/ Archived-At: Subject: [EAI] Fwd: [UA-discuss] UA Internationalization Project Group kicks off! X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 22:41:21 -0000 --Apple-Mail-8FA0CC3B-CBEA-41FA-818C-B9F46A4077A1 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: quoted-printable For those who might be interested in it, the following list may be helpful. https://mm.icann.org/mailman/listinfo/ua-international =46rom my phone > =B7=A2=BC=FE=C8=CB: "Tan Tanaka, Dennis" > =C8=D5=C6=DA: 2015=C4=EA4=D4=C223=C8=D5 GMT+85:50:39 > =CA=D5=BC=FE=C8=CB: "ua-international@icann.org" > =B3=AD=CB=CD: "UA-discuss@icann.org" > =D6=F7=CC=E2: [UA-discuss] UA Internationalization Project Group kicks off= ! >=20 > Dear Project Group members, > =20 > The Internationalization (i18n for short) Project Group is open for busine= ss! > =20 > Here are a few items to get us started. > =20 > Scope > The i18n Project Group will be focused on the IDN ecosystem as it pertains= to these four major categories: > 1. Standards (i.e., IETF, Unicode, W3C) > 2. Practices (i.e. guidelines established by others) > 3. Tools (i.e., apis, programming languages) > 4. Applications (e.g. browsers, email clients, other apps) > By IDN ecosystem we mean IDNA, EAI and IRI > =20 > > =20 > =20 > Next Steps and action items > 1. Increase membership =A8C We don=A1=AFt pretend to know it all. We= need help! Please share the mailing list address to anyone who you think is= interested in the subject of IDNs, EAI and IRIs. https://mm.icann.org/mailm= an/listinfo/ua-international > 2. Meetings =A8C Our first group meeting will be in the week of May 1= 1. This will allow Dusan and I time to prepare so that we have a meaningful a= nd productive discussion. I will circulate a doodle poll to agree on a time.= > =20 > Best, > Dennis > =20 > =20 >=20 --Apple-Mail-8FA0CC3B-CBEA-41FA-818C-B9F46A4077A1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
For those who might be interested= in it, the following list may be helpful.


=E5=8F=91= =E4=BB=B6=E4=BA=BA: "Tan Tanaka, Dennis" <dtantanaka@verisign.com>
=E6=97=A5=E6=9C=9F: 2015=E5=B9=B44=E6=9C=8823=E6=97=A5 GMT+85:50:39
=E6=94=B6=E4=BB=B6=E4= =BA=BA: "ua-international@= icann.org" <ua-internat= ional@icann.org>
=E6=8A=84=E9=80=81: "UA-discuss@icann.org" <UA-discuss@icann.org>
=E4=B8=BB=E9=A2=98: [= UA-discuss] UA Internationalization Project Group kicks off!

Dear Project Group members,

 

The Internationalization (i18n for short) Project Gro= up is open for business!

 

Here are a few items to get us started.

 

Scope

The i18n Project Group will be focused on the IDN eco= system as it pertains to these four major categories:

1.     &= nbsp; Standards (i.e., IETF, Unicode, W3C)<= /p>

2.     &= nbsp; Practices (i.e. guidelines established by others= )

3.     &= nbsp; Tools (i.e., apis, programming languages)

4.     &= nbsp; Applications (e.g. browsers, email clients, othe= r apps)

By IDN ecosystem we mean IDNA, EAI and IRI=

 

<image002.jpg>

 

 

Next Steps and action items<= /p>

1.     &= nbsp; Increase membership =E2=80=93 We don=E2=80=99t p= retend to know it all. We need help! Please share the mailing list address t= o anyone who you think is interested in the subject of IDNs, EAI and IRIs. https://m= m.icann.org/mailman/listinfo/ua-international

2.     &= nbsp; Meetings =E2=80=93 Our first group meeting will b= e in the week of May 11. This will allow Dusan and I time to prepare so that= we have a meaningful and productive discussion. I will circulate a doodle p= oll to agree on a time.

 

Best,

Dennis

 

 


= --Apple-Mail-8FA0CC3B-CBEA-41FA-818C-B9F46A4077A1-- From nobody Wed Apr 22 19:06:51 2015 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8371A00FB for ; Wed, 22 Apr 2015 19:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 EPFuUGyEnmaK for ; Wed, 22 Apr 2015 19:06:48 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id A6DC51A00F3 for ; Wed, 22 Apr 2015 19:06:47 -0700 (PDT) Received: from healthyao-THINK (unknown [218.241.103.204]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0A5QZW1UzhVMps3AA--.201S2; Thu, 23 Apr 2015 10:06:45 +0800 (CST) Date: Thu, 23 Apr 2015 10:06:46 +0800 From: "Jiankang Yao" To: "Franck Martin" References: , <2014122416222946049414@cnnic.cn> <74AB4E55C973F120425B40D4@JcK-HP8200.jck.com>, <1D64B26D-14FE-4376-BAF6-A00DBAD3B2D6@linkedin.com> <2014122509222303016622@cnnic.cn>, <7C45B427-47E4-4337-A2D2-1275BEA3166F@linkedin.com> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.92[cn] Mime-Version: 1.0 Message-ID: <201504231005444679293@cnnic.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart341726837887_=----" X-CM-TRANSID: AQAAf0A5QZW1UzhVMps3AA--.201S2 X-Coremail-Antispam: 1UD129KBjDUn29KB7ZKAUJUUUUU529EdanIXcx71UUUUU7v73 VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjp_UUUYA7k0a2IF6F4UM7kC6x804xWl14x267AK xVWUJVW8JwAFc2x0x2IEx4CE42xK8VAvwI8IcIk0rVWrJVCq3wAFIxvE14AKwVWUJVWUGw A2ocxC64kIII0Yj41l84x0c7CEw4AK67xGY2AK021l84ACjcxK6xIIjxv20xvE14v26F1j 6w1UM28EF7xvwVC0I7IYx2IY6xkF7I0E14v26F4j6r4UJwA2z4x0Y4vEx4A2jsIE14v26r 4UJVWxJr1l84ACjcxK6I8E87Iv6xkF7I0E14v26F4UJVW0owAS0I0E0xvYzxvE52x082IY 62kv0487Mc02F40E42I26xC2a48xMcIj6xIIjxv20xvE14v26r1j6r18McIj6I8E87Iv67 AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IYc2Ij64vIr41lFcxC0VAYjxAx ZF0Ew4CEw7xC0wACY4xI67k04243AVC20s07MxkIecxEwVAFwVW8JwCF04k20xvY0x0EwI xGrwCFx2IqxVCFs4IE7xkEbVWUJVW8JwC20s026c02F40E14v26r106r1rMI8I3I0E7480 Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_JF0_Jw1lIxkGc2Ij64vIr41lIxAIcVC0I7 IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1lIxAIcVCF04k2 6cxKx2IYs7xG6rWUJVWrZr1UMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2jsIEc7 CjxVAFwI0_Gr0_Gr1UMVCEFcxC0VAYjxAxZFUvcSsGvfC2KfnxnUUI43ZEXa7IU82ZX7UU UUU== X-CM-SenderInfo: x1dryyw6fq0xffof0/ Archived-At: Cc: ima , "xxxia@coremail.cn" , "'marvin.woo'" Subject: Re: [EAI] Chinese email address X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: yaojk List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 02:06:50 -0000 This is a multi-part message in MIME format. ------=_001_NextPart341726837887_=---- Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 DQpIZWxsbywNCg0KICBJIGhhdmUgZm9yd2FyZGVkIHRoaXMgbWVzc2FnZSB0byBjb3JlbWFpbCwg d2hvIHdpbGwgaGVscCB0byBkbyBpdC4NCg0KICBUaGFua3MgZm9yIHlvdXIga2luZCBtZXNzYWdl Lg0KDQoNCg0KDQpKaWFua2FuZyBZYW8NCg0KRnJvbTogRnJhbmNrIE1hcnRpbg0KRGF0ZTogMjAx NS0wNC0yMiAxNjowNw0KVG86IHlhb2prDQpDQzogSm9obiBDIEtsZW5zaW47IGltYQ0KU3ViamVj dDogUmU6IFtFQUldIENoaW5lc2UgZW1haWwgYWRkcmVzcw0KSmlhbmthbmcsDQoNCg0KZGVidWdn aW5nIHNvbWUgbW9yZS4uLg0KDQoNCkNvdWxkIHlvdSBwbGVhc2UgcHV0IGFuIFNQRiBvbiB4bi0t YmxxNTEwamd3YS54bi0tNTVxeDVkDQoNCg0KQWxzbyBJIG5vdGljZSB5b3UgcmVxdWlyZSBTUEYg cGFzcyB0byBlbWFpbCB0aGlzIGRvbWFpbiwgb3RoZXJ3aXNlIHlvdSBnZXQgdGhlIGVycm9yOg0K NDUwIFJlcXVlc3RlZCBtYWlsIGFjdGlvbiBub3QgdGFrZW46IEludmFsaWQgSVANCg0KDQphIDQ1 MCBpcyBhIGJpdCBiYWQsIGVpdGhlciBTUEYgcGFzcyBvciBpdCBkb2VzIG5vdCwgU1BGIHRlbXAg ZmFpbHVyZXMgYXJlIHJhcmUgKGJ1dCBub3QgdW5jb21tb24pIHNvIGl0IHNob3VsZCBoYXZlIGJl ZW4gYSA1NTAu ------=_001_NextPart341726837887_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
 
Hello,
 
  I have forwarded this message to coremail, who will help to do= =20 it.
 
  Thanks for your kind message.
 
Jiankang Yao
 
Date: 2015-04-22 16:07
To: yaojk
CC: John C Klensin= ; ima
Subject: Re: [EAI] Chinese email address
Jiankang,

debugging some more...

Could you please put an SPF on xn--blq510jgwa.xn--55qx5d

Also I notice you require SPF pass to email this domain, otherwise yo= u get=20 the error:
450=20 Requested mail action not taken: Invalid IP

a 450 is a bit bad, either SPF pass or it does not, SPF temp failures= are=20 rare (but not uncommon) so it should have been a 550.


------=_001_NextPart341726837887_=------ From nobody Fri Apr 24 03:15:31 2015 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 078D81A7000 for ; Fri, 24 Apr 2015 03:15:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.298 X-Spam-Level: X-Spam-Status: No, score=0.298 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 TJzyBnXoXDUd for ; Fri, 24 Apr 2015 03:15:28 -0700 (PDT) Received: from APAC01-HK1-obe.outbound.protection.outlook.com (mail-hk1on0116.outbound.protection.outlook.com [134.170.140.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B61561A6FF2 for ; Fri, 24 Apr 2015 03:15:27 -0700 (PDT) Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none; Received: from [133.2.210.64] (133.2.210.64) by TY1PR01MB0141.jpnprd01.prod.outlook.com (25.161.134.13) with Microsoft SMTP Server (TLS) id 15.1.148.16; Fri, 24 Apr 2015 10:15:25 +0000 Message-ID: <553A17B6.5090803@it.aoyama.ac.jp> Date: Fri, 24 Apr 2015 19:15:18 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: John C Klensin , Oleksandr Tsaruk References: <3D9223A5-135E-4F43-B814-EB7BE51D207C@linkedin.com> <01PKTYIGGNDC0000AQ@mauve.mrochek.com> In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [133.2.210.64] X-ClientProxiedBy: TY1PR01CA0024.jpnprd01.prod.outlook.com (25.161.131.162) To TY1PR01MB0141.jpnprd01.prod.outlook.com (25.161.134.13) X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:TY1PR01MB0141; X-Forefront-Antispam-Report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(6049001)(479174004)(24454002)(92566002)(86362001)(87976001)(93886004)(85182001)(4001350100001)(59896002)(23676002)(66066001)(64126003)(77156002)(54356999)(62966003)(65816999)(50466002)(65806001)(65956001)(5001770100001)(87266999)(2950100001)(50986999)(76176999)(74482002)(122386002)(40100003)(46102003)(80316001)(42186005)(33656002)(83506001)(3940600001); DIR:OUT; SFP:1102; SCL:1; SRVR:TY1PR01MB0141; H:[133.2.210.64]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(5002010)(5005006)(3002001); SRVR:TY1PR01MB0141; BCL:0; PCL:0; RULEID:; SRVR:TY1PR01MB0141; X-Forefront-PRVS: 05568D1FF7 X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Apr 2015 10:15:25.0928 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY1PR01MB0141 Archived-At: Cc: ima@ietf.org Subject: Re: [EAI] UTF32 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 10:15:30 -0000 On 2015/04/22 22:21, John C Klensin wrote: > Now you may be thinking about something else. The Unicode code > space ranges only from 0 to 0x10FFFF. A 32bit code space would > be 0 to 0xFFFFFFFF. If one believed that the Unicode code space > were too small and that a full 32 bit space were needed, that > would be a different matter entirely. The Unicode folks are > convinced that more than the current space will never be needed > to represent all symbols of interest but, at one stage, they > believed that a 16bit code space would be enough. I haven't > studied the mechanisms in some years, but, if a larger code > space were needed, extensions would be needed to both the UTF-8 > and UTF-16 encoding models to accommodate it while anything that > used a 32 bit space directly would presumably be fairly > transparent, at least until one got into various Unicode tables > and algorithms that assume the smaller code space. But, again, > that has little to do with the difference between UTF-16 and > UTF-32 except as a side effect. More specifically, at one point, Unicode thought that a 16-bit space might be enough (for that time being, at least), while on the other hand ISO/IEC JTC1/SC2/WG2, the ones responsible for ISO 10646, thought that an architecture with a full 31 bits would be better (the 32nd bit was always reserved because nobody wanted to repeat the 8-bit "signed char" vs. "unsigned char" mess). UCS-4 and UTF-8 were both designed to encompass this 31-bit code space. UTF-8 needed up to 6 bytes for a character, in a very straightforward way, according to its original design (There is still code out there with traces from this period.). UCS-2 was of course limited to 16 bits. With time passing, it became clearer on both sides that 16 bits wasn't enough but 31 bits was overkill. The introduction of UTF-16 created an upper limit of 0x10FFFF in one of the Unicode encoding forms. Therefore both Unicode and SC2/WG2 agreed on this overall limit. UTF-32 was introduced as a version of UCS-4 with an explicit upper codepoint limit of 0x10FFFF, and the definition of UTF-8 was changed to only go up to four bytes. In the case of an extraterrestrial invasion by a culture with millions of characters or a sudden excessive emoji binge, the limits for UCS-32 and UTF-8 could be changed again, and some further kludge could be introduced in UTF-16. But the chance that we'll get there is very low, at least for the moment. Regards, Martin. From nobody Fri Apr 24 05:06:39 2015 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 293FA1ABC74 for ; Fri, 24 Apr 2015 05:06:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.699 X-Spam-Level: X-Spam-Status: No, score=0.699 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 tBcqguSWxiyI for ; Fri, 24 Apr 2015 05:06:36 -0700 (PDT) Received: from st15.mi6.kiev.ua (st15.mi6.kiev.ua [91.198.36.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A4011AC43D for ; Fri, 24 Apr 2015 05:06:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=i.ua; s=mail; h=Message-Id:Content-Transfer-Encoding:Content-Type:References:MIME-Version:Date:In-Reply-To:Cc:From:Subject:To; bh=X9FcqHj57gFv90fFmfAgztkY2KC+Mrs8VTdnkJpBeMQ=; b=FFct1uCvA95JLJuwUxCAwb0Z2yrRZa6EyaOyJBpqwDflmV9ANxL2BDnGaUl8lWrfPTBvbaWLRrtpcrm9nRuQ8bUqysNE7e16/Tf0z75VMjE/LqpYZrzqYlkTQ4njTxGcyUZp3xP3Dzpik5fubk6f3/Vah3Syf4Yr+t5Dk+Q6bjM=; Received: from web by st15.mi6.kiev.ua with local (Exim 4.80.1) (envelope-from ) id 1YlcNL-0004xm-HF; Fri, 24 Apr 2015 15:06:31 +0300 To: duerst@it.aoyama.ac.jp From: Oleksandr Tsaruk In-Reply-To: <553A17B6.5090803@it.aoyama.ac.jp> Date: Fri, 24 Apr 2015 15:06:31 +0300 MIME-Version: 1.0 References: <3D9223A5-135E-4F43-B814-EB7BE51D207C@linkedin.com> <01PKTYIGGNDC0000AQ@mauve.mrochek.com> <553A17B6.5090803@it.aoyama.ac.jp> X-Mailer: I.UA Mail System X-Server: st15.mi6.kiev.ua X-Sender-IP: 193.19.152.14 (192.168.40.33) X-User-Agent: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.90 Safari/537.36 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Message-Id: Archived-At: Cc: ima@ietf.org Subject: Re: [EAI] =?utf-8?q?UTF32?= X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 12:06:39 -0000 Dear colleagues I am very glad that I successfully have drawn your attention, I an new at IETF, and participated only Dallas meeting but have got some experience at IDN board and at ICANN GAC. We saw that Punycode solving basic IDN problems but have no perspectives. That is why I posted this provocative question on UTF32 and glad to see development of idea in ISO/IEC JTC1/SC2/WG2. The basic propose is to find solution for IDN domains and email addresses be present in original scripts. Best regards, Oleksandr Tsaruk 24.04.2015 13:15, "\"Martin J. Drst\"" >On 2015/04/22 22:21, John C Klensin wrote: > > > Now you may be thinking about something else. The Unicode code > > space ranges only from 0 to 0x10FFFF. A 32bit code space would > > be 0 to 0xFFFFFFFF. If one believed that the Unicode code space > > were too small and that a full 32 bit space were needed, that > > would be a different matter entirely. The Unicode folks are > > convinced that more than the current space will never be needed > > to represent all symbols of interest but, at one stage, they > > believed that a 16bit code space would be enough. I haven't > > studied the mechanisms in some years, but, if a larger code > > space were needed, extensions would be needed to both the UTF-8 > > and UTF-16 encoding models to accommodate it while anything that > > used a 32 bit space directly would presumably be fairly > > transparent, at least until one got into various Unicode tables > > and algorithms that assume the smaller code space. But, again, > > that has little to do with the difference between UTF-16 and > > UTF-32 except as a side effect. > > More specifically, at one point, Unicode thought that a 16-bit space > might be enough (for that time being, at least), while on the other hand > ISO/IEC JTC1/SC2/WG2, the ones responsible for ISO 10646, thought that > an architecture with a full 31 bits would be better (the 32nd bit was > always reserved because nobody wanted to repeat the 8-bit "signed char" > vs. "unsigned char" mess). UCS-4 and UTF-8 were both designed to > encompass this 31-bit code space. UTF-8 needed up to 6 bytes for a > character, in a very straightforward way, according to its original > design (There is still code out there with traces from this period.). > UCS-2 was of course limited to 16 bits. > > With time passing, it became clearer on both sides that 16 bits wasn't > enough but 31 bits was overkill. The introduction of UTF-16 created an > upper limit of 0x10FFFF in one of the Unicode encoding forms. Therefore > both Unicode and SC2/WG2 agreed on this overall limit. UTF-32 was > introduced as a version of UCS-4 with an explicit upper codepoint limit > of 0x10FFFF, and the definition of UTF-8 was changed to only go up to > four bytes. > > In the case of an extraterrestrial invasion by a culture with millions > of characters or a sudden excessive emoji binge, the limits for UCS-32 > and UTF-8 could be changed again, and some further kludge could be > introduced in UTF-16. But the chance that we'll get there is very low, > at least for the moment. > > Regards, Martin. Sincerely yours, Oleksandr Tsaruk, Ph.D. -- реклама ----------------------------------------------------------- Поторопись зарегистрировать самый короткий почтовый адрес @i.ua http://mail.i.ua/reg - и получи 1Gb для хранения писем From nobody Fri Apr 24 11:34:56 2015 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB3871A8890 for ; Fri, 24 Apr 2015 11:34:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.31 X-Spam-Level: X-Spam-Status: No, score=-2.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 oFjHHYNtXG-I for ; Fri, 24 Apr 2015 11:34:53 -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 EC96F1ACDF2 for ; Fri, 24 Apr 2015 11:34:51 -0700 (PDT) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YliR3-000Ifq-Gv; Fri, 24 Apr 2015 14:34:45 -0400 Date: Fri, 24 Apr 2015 14:34:40 -0400 From: John C Klensin To: =?UTF-8?Q?=22Martin_J=2E_D=C3=BCrst=22?= , Oleksandr Tsaruk Message-ID: <3F4D1D41BF532675751552D2@JcK-HP8200.jck.com> In-Reply-To: <553A17B6.5090803@it.aoyama.ac.jp> References: <3D9223A5-135E-4F43-B814-EB7BE51D207C@linkedin.com> <01PKTYIGGNDC0000AQ@mauve.mrochek.com> <553A17B6.5090803@it.aoyama.ac.jp> 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.35 X-SA-Exim-Mail-From: klensin@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: ima@ietf.org Subject: Re: [EAI] UTF32 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 18:34:55 -0000 --On Friday, April 24, 2015 19:15 +0900 "\"Martin J. = D=C3=BCrst\"" wrote: >... > More specifically, at one point, Unicode thought that a 16-bit > space might be enough (for that time being, at least), while > on the other hand ISO/IEC JTC1/SC2/WG2, the ones responsible > for ISO 10646, thought that an architecture with a full 31 > bits would be better (the 32nd bit was always reserved because > nobody wanted to repeat the 8-bit "signed char" vs. "unsigned > char" mess). UCS-4 and UTF-8 were both designed to encompass > this 31-bit code space. UTF-8 needed up to 6 bytes for a > character, in a very straightforward way, according to its > original design (There is still code out there with traces > from this period.). UCS-2 was of course limited to 16 bits. >... Martin, Yes. And thanks for the additional details. I think the bottom line, at least barring some very unlikely events (such as the extraterrestrial invasion you mention or a change to conventions about what gets encoded such as the breakdown in Han Unification that the article Franck pointed to seems to request), is that we are not even close to exhausting that 0x10FFFF limit and hence, whatever the issues are, not having the full 31 bit (as you correctly point out) range available is not in the critical path. Now, there is a lot to dislike about Unicode. Depending on one's starting perspective about coding system design, one can come up with different preferences and priorities. It is reasonably clear, at least in retrospect, that some scripts and writing systems have been better treated than others. Adjustments made for better compatibility with earlier standards for particular language-based repertoires (some of which involved compromises to fit in seven or eight bit code spaces), led to later inconsistencies or other difficulties. However, there are no other realistic candidates for a "universal" character encoding system and, while a hypothetical system based on a different set of rules, priorities, and tradeoffs might easily demonstrate a different collection of difficulties, there is no evidence at all that it would be objectively better... just different. So here we are, with a coding system that will never be perfect, possibly because we'd really like a consistent and predictable set of rules that apply across the entire code space but that neither the diversity of human (to say nothing of extraterrestrial) languages and writing systems nor the politics and conflicts over priorities that always intrude on such standards lend themselves to that level of consistency and predictability. Building on top of Unicode to fit well with particular applications can be hard, but we seem to have little choice other than to keep trying (see, e.g., IDNA and PRECIS as well as the recent LUCID discussions and the associated drafts). Whatever the path forward, it is clear to me that there is no plausible path for email addresses that adopts a fundamentally different character coding system or underlying repertoire than what the rest of the IETF (and mostly the rest of the world) are doing. john From nobody Fri Apr 24 12:22:24 2015 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD1661B3871 for ; Fri, 24 Apr 2015 12:22:22 -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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 210Bi6F-AHrw for ; Fri, 24 Apr 2015 12:22:21 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0751.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:751]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BCBA1B386C for ; Fri, 24 Apr 2015 12:22:20 -0700 (PDT) Received: from BLUPR03MB1378.namprd03.prod.outlook.com (25.163.81.12) by BLUPR03MB1378.namprd03.prod.outlook.com (25.163.81.12) with Microsoft SMTP Server (TLS) id 15.1.148.16; Fri, 24 Apr 2015 19:21:59 +0000 Received: from BLUPR03MB1378.namprd03.prod.outlook.com ([25.163.81.12]) by BLUPR03MB1378.namprd03.prod.outlook.com ([25.163.81.12]) with mapi id 15.01.0148.008; Fri, 24 Apr 2015 19:21:59 +0000 From: Shawn Steele To: "ima@ietf.org" Thread-Topic: IDN in Unicode Thread-Index: AdB+wzxbuAHnFuVPQUWDnfS4KK0oWw== Date: Fri, 24 Apr 2015 19:21:58 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-originating-ip: [2001:4898:80e0:ee43::5] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1378; x-microsoft-antispam-prvs: x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(2351001)(107886001)(50986999)(33656002)(99286002)(62966003)(77156002)(102836002)(110136001)(2501003)(74316001)(450100001)(92566002)(76576001)(229853001)(122556002)(54356999)(46102003)(86362001)(2656002)(40100003)(87936001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1378; H:BLUPR03MB1378.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010)(3002001); SRVR:BLUPR03MB1378; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1378; x-forefront-prvs: 05568D1FF7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Apr 2015 19:21:58.9534 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1378 Archived-At: Subject: [EAI] IDN in Unicode X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 19:22:23 -0000 > The basic propose is to find solution for IDN domains and email addresses= be present in original scripts. =20 That seems like a completely different discussion than "let's use UTF-32". = =20 Many applications handle domain names natively in either UTF-8 or UTF-16, e= ither of which are sufficient to describe the domains in their original scr= ipts. =20 Punycode is kind of a hack to provide a mechanism to resolve domain names u= sing the preexisting infrastructure that is limited to the ASCII space. Ho= wever many applications, like EAI, prefer UTF-8. Our recommendations provide for IDN to be looked up with Punycode only in t= he resolution phase. For many apps that is transparent to the app and they= can just use Unicode with the system API set. Some apps, however may need= to recognize Punycode domains for whatever reason or additional protocol l= imitations. However in those cases it is still recommended that they prefe= r Unicode and only use the Punycode when absolutely necessary. -Shawn From nobody Fri Apr 24 16:44:26 2015 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9AA31ACE24 for ; Fri, 24 Apr 2015 16:44:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 AkxHo2vu1CYH for ; Fri, 24 Apr 2015 16:44:24 -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 EC6B71ACDF8 for ; Fri, 24 Apr 2015 16:44:23 -0700 (PDT) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YlnGZ-000J9m-Dc; Fri, 24 Apr 2015 19:44:15 -0400 Date: Fri, 24 Apr 2015 19:44:10 -0400 From: John C Klensin To: Shawn Steele , ima@ietf.org Message-ID: In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: klensin@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [EAI] IDN in Unicode X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 23:44:25 -0000 --On Friday, April 24, 2015 19:21 +0000 Shawn Steele wrote: >> The basic propose is to find solution for IDN domains and >> email addresses be present in original scripts. > > That seems like a completely different discussion than "let's > use UTF-32". I think that is the point that Martin, Andrew, myself, and maybe others have been trying to make. > Many applications handle domain names natively in either UTF-8 > or UTF-16, either of which are sufficient to describe the > domains in their original scripts. > > Punycode is kind of a hack to provide a mechanism to resolve > domain names using the preexisting infrastructure that is > limited to the ASCII space. However many applications, like > EAI, prefer UTF-8. I wouldn't characterize either the Punycode algorithm or its results in quite that way. It may be that one person's hack is someone else's elegant solution. It is also worth noting that Punycode is part of a fairly complex system of rules for IDNA that deal with a number of issues other than the ASCII-compatibility one. If it were not for those issues, it might have been plausible to note that the DNS can support labels containing of a string of arbitrary octets, develop a convention for identifying such strings as containing UTF-8 when appropriate, and then simply tell people to wait until the relevant protocols were upgraded. There are multiple reasons why IDNA (and hence the Punycode algorithm) was a better idea for domain names, with two important ones being the symbolic importance of claiming to have deployed IDNs and the desire of some members of the ICANN community to start selling IDN labels as soon as possible with usability as a secondary consideration. > Our recommendations provide for IDN to be looked up with > Punycode only in the resolution phase. For many apps that is > transparent to the app and they can just use Unicode with the > system API set. Some apps, however may need to recognize > Punycode domains for whatever reason or additional protocol > limitations. However in those cases it is still recommended > that they prefer Unicode and only use the Punycode when > absolutely necessary. That is in essence what RFC 6055 says although there are some nuances that might be worth attention. In addition and independent of when the Punycode algorithm is applies, there are some significant advantages to applying the tests for U-label validity as early in the process as possible. If that is not done, error reporting is likely to deteriorate into "you lose" or complaining about strings the user has never seen rather than being able to report problems to users in and with contexts that make sense to them. john