From nobody Wed Feb 8 06:31:53 2017 Return-Path: X-Original-To: precis@ietf.org Delivered-To: precis@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DB1E129B45; Wed, 8 Feb 2017 06:31:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.42.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148656431257.3739.5832845443696976007.idtracker@ietfa.amsl.com> Date: Wed, 08 Feb 2017 06:31:52 -0800 Archived-At: Cc: precis-chairs@ietf.org, aamelnikov@fastmail.fm, precis@ietf.org Subject: [precis] precis - Not having a session at IETF 98 X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.17 List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 14:31:52 -0000 Marc Blanchet, a chair of the precis working group, indicated that the precis working group does not plan to hold a session at IETF 98. This message was generated and sent by the IETF Meeting Session Request Tool. From nobody Sun Feb 12 11:27:31 2017 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18CCE129AC6 for ; Sun, 12 Feb 2017 11:27:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=stpeter.im header.b=RympYsi7; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=E3sddI3z 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 Egdl4FIAnCLC for ; Sun, 12 Feb 2017 11:27:28 -0800 (PST) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DB94129AC2 for ; Sun, 12 Feb 2017 11:27:28 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailnew.nyi.internal (Postfix) with ESMTP id E4759C5A; Sun, 12 Feb 2017 14:27:25 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Sun, 12 Feb 2017 14:27:25 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=stpeter.im; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=Q2dwamZ1b3jOf0z rVVIA3UzGO08=; b=RympYsi7bTswXE/ci7N6GBXV/GGyqu4gp/w3+trxoEres0t c+tSUHpOyxhkvM1Z+d7vbJlCWJ3kuhFvvUa3WfyFfR/rU03ejksyL+VgeX42kq1T NknzGsKtN9txlEzgFMVpo2SRWFZePOGX1c9W5lsfpiDK95t7+ldDjrMvHMBM= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= smtpout; bh=Q2dwamZ1b3jOf0zrVVIA3UzGO08=; b=E3sddI3zY+8h4y4DtZF/ XLOyh6rNq5t8+rmwBewZRR/lYLxoa/pRLfst1qCSDRZTTKJ/EhSge3+Ki7bnOFqD dG6zIcoJ4/2hIEySBSTR7bNF8t9J1OlK/yHUIVb2FSd+LeXj8J+gmOF15uaLC/VW O+ndUu2ki2gcZ9CGi48RMBY= X-ME-Sender: X-Sasl-enc: CGMESeLpfO6ekJeMSh7iwm9dvH7U9PLgf+ko/mGVgReg 1486927645 Received: from aither.local (unknown [76.25.4.24]) by mail.messagingengine.com (Postfix) with ESMTPA id D76B77E273; Sun, 12 Feb 2017 14:27:24 -0500 (EST) To: William Fisher References: From: Peter Saint-Andre Message-ID: <15c31273-c278-af61-2a01-0b68ab8af182@stpeter.im> Date: Sun, 12 Feb 2017 12:27:24 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: precis@ietf.org Subject: Re: [precis] Enforcement as an Idempotent operation X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2017 19:27:30 -0000 Hi Bill, thanks for your message and sorry about the seriously delayed reply - I've been working to finish some other Internet-Drafts and now have time again to finish the PRECIS updates. On 10/13/16 1:33 PM, William Fisher wrote: > On Wed, Oct 12, 2016 at 9:03 PM, Peter Saint-Andre wrote: >> It's not clear to me that U+1F11 has the problem you describe; perhaps could you sketch it out further? > > Oops, that should be U+0001F11A. Did you mean U+212A (KELVIN SIGN)? That decomposes to U+004B (LATIN CAPITAL LETTER K). > The full example is: > "\U0001f11aevin" => "(K)evin" => "(k)evin" Yes, "U+212Aevin" => "Kevin" via NFKC. However, "U+212Aevin" => "kevin" via toLower() if I am not mistaken. > I wrote a program to categorize characters that are not idempotent > under Nickname "ToLower" (ignoring white space). The numbers are the > same for Unicode 6.3, 8.0 and 9.0. > > { > '': 467, > '': 90, > '': 35, > '': 27, > '': 4 > } Would you mind sending me your list of characters? (I'm happy to receive it off-list.) I suspect that it might be similar to a list that emerged from differing assumptions regarding how to apply the PRECIS rules in implementations. My original implementation for testing purposes was rather naïve, whereas the implementation that Yoshiro Yoneya and Takahiro Nemoto created was smarter, in the sense that it would follow the chain of characters and decompose each one fully as it went along (this might require a few rounds of applying the normalization rule in order to fully decompose the original characters). > The following two characters also appear to fail the idempotent test. > The initial decompositions do not begin with '<'. > > \u03d3 GREEK UPSILON WITH ACUTE AND HOOK SYMBOL > \u03d4 GREEK UPSILON WITH DIAERESIS AND HOOK SYMBOL These examples are different from the KELVIN SIGN example, because there is no direct toLower() transformation - normalization needs to happen before toLower() is applied. >> Thanks for your input. Personally I will think about it further and post again after I do so. > > To me, the problem is to take untrusted input, validate it using > specified rules, and transform it into a stable, unambiguous format. > I'm still learning more about Unicode. Trust me: it never ends. > Is there a reason that the case > mapping rule has to be applied *before* the normalization rule? As explained in Section 5.2.1 of RFC 7564, there is a good reason to apply the width mapping rule before the normalization rule. I'm now less sure that it makes sense, for comparison purposes, to apply the case mapping rule before the normalization rule. > The > order appears to make a difference for NFKC. I suppose the Nickname > "comparison" profile could re-apply the case mapping rule after the > normalization rule? If I understand correctly, you are suggesting that an implementation that is processing nickname strings for purposes of comparison would do the following: 1. Apply the "enforcement" action in Section 2.3 2. Apply the "comparison" action in Section 2.4 Let's choose a practical but somewhat contrived example: a nickname of ΨϓΧΗ, which is U+03A8 U+03D3 U+03A7 U+0397 (something like an uppercase version of the Greek word for soul, although the accent is wrong). This includes the code point U+03D3 that you mention above (which, by the way, is not the standard code point for the Greek letter upsilon but an alternative with a hook symbol, the usual character being U+03A5). The two-step process you suggest would involve the following: 1. The "enforcement" action results in normalization (note that full normalization involves several steps): U+03A8 U+03D3 U+03A7 U+0397 => U+03A8 U+03D2 U+0301 U+03A7 U+0397 => U+03A8 U+03A5 U+0301 U+03A7 U+0397 (note that U+03D2 has a compatibility equivalent of U+03A5) 2. The "comparison" action results in case mapping: U+03A8 U+03A5 U+0301 U+03A7 U+0397 => U+03C8 U+03C5 U+0301 U+03C7 U+03B7 Thus, for comparison purposes, ΨϓΧΗ and ψύχη would be considered equivalent. Unfortunately, even though that seems to yield the correct outcome, it's not what RFC 7700 specifies. I'll continue to think about this - in particular, about any negative implications from modifying the order of operations so that normalization comes before case mapping (unlike what we specified in RFC 7700). Because we would prefer that all the PRECIS specs follow the same order, we'd also need to look at the implications for RFC 7613 (although the OpaqueString profile that we use there for passwords has quite a different purpose than the Nickname profile in RFC 7700); however, this might not be possible. Peter From nobody Sun Feb 12 13:48:17 2017 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0522129B63 for ; Sun, 12 Feb 2017 13:48:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=stpeter.im header.b=tFdHbJID; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=CfS+aAVu 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 wAX4iuUnOP53 for ; Sun, 12 Feb 2017 13:48:15 -0800 (PST) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3DE6129413 for ; Sun, 12 Feb 2017 13:48:15 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailnew.nyi.internal (Postfix) with ESMTP id 1B9D11958; Sun, 12 Feb 2017 16:48:15 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Sun, 12 Feb 2017 16:48:15 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=stpeter.im; h= content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=dig2/dmYuQqscmijPYWnjhO+KEQ=; b=tFdHbJ IDCLRCPG6ppYoPecnSZwR0aRb+/SkuUwqSIcO3kihAx+/nQel1x5lDxKq2qMokHc tLVLAsPpjkqNTNPUt/cb2jmAyg5sqfBQADDWzAl5pfbXeaFkuFwvatC0//etaLoZ jMlO7KOmLxt27nwtZhDec2GOcIkTUjh2na6ps= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=smtpout; bh=dig2/dmYuQqscm ijPYWnjhO+KEQ=; b=CfS+aAVuq9rf8ZGOZlfc9QXOWrCpbHRnZjwiLueqah1VSy AoMB+k5wmPndON2G8HhndYDTV9CpkbL6Xxdf+qlwCPfQRJ5v49887EPXLFr4o/ya qsKWzoesx937w7I2YLAYNbWfXyqyd7uJ4skHMoB8oTv4dlFb6cCyc1i71kfIU= X-ME-Sender: X-Sasl-enc: r1T3fOl3pr8ruG8JE75gIsXjvMagkkUanmrJOVyqkabT 1486936094 Received: from aither.local (unknown [76.25.4.24]) by mail.messagingengine.com (Postfix) with ESMTPA id 8BC147E2E6; Sun, 12 Feb 2017 16:48:14 -0500 (EST) To: "precis@ietf.org" From: Peter Saint-Andre Message-ID: <3b1a3932-da73-2ccb-115f-f5da4964ad13@stpeter.im> Date: Sun, 12 Feb 2017 14:48:13 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [precis] HasCompat() X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2017 21:48:17 -0000 In an off-list conversation, John Klensin pointed out to me that there could be confusion about the definition of the HasCompat() category from Section 9.17 of RFC 7564 and of draft-ietf-precis-7564bis-04. I can't speak for my co-author Marc Blanchet, but I've always considered HasCompat to apply in a "unidirectional" way to the input characters. For instance, if we have three code points P0, P1, and P2 such that NFKC(P1P2) = P0P0, then the HasCompat() category is assigned to P1 and P2 but not to P0. That is, P1 and P2 are decomposed and then recomposed in a lossy way because we can't tell from the output string P0P0 what the input string was, and there is way to determine all the characters that could be decomposed and recomposed into P0P0. It seems that the current text might be a bit confusing (as I understand what John wrote, the term "has a compatibility equivalent" could be taken to apply to P0 in this example), so I will try to make it clearer. Furthermore, John pointed out that the HasCompat() categorization for a given input string could potentially change across Unicode versions (e.g., if the input string includes a precomposed character that was added in a recent version of Unicode). Although I'm not sure if this is unavoidable, it does seem that we need to at least mention the potential instability of this category. Peter From nobody Sun Feb 12 15:29:59 2017 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5068129404 for ; Sun, 12 Feb 2017 15:29:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=stpeter.im header.b=A2kvUOzh; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=Ca86nPTf 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 HXhGZagjRMaq for ; Sun, 12 Feb 2017 15:29:56 -0800 (PST) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 569C71293FE for ; Sun, 12 Feb 2017 15:29:56 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailnew.nyi.internal (Postfix) with ESMTP id 7238319F6; Sun, 12 Feb 2017 18:29:55 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Sun, 12 Feb 2017 18:29:55 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=stpeter.im; h= content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=CIcMfwlSsNJkrDkR4paMt0V6VCs=; b=A2kvUO zhlGIh8dBbM3I1HfZ3naQErbr2YXnfJphOEVvqWvYPafbYz7tBkcxF9oqVB4usQS BPGwH6whDyEVVQ0ek/itC5adxGCHNASb/vDfAAYgYOpQXzrTbkC5NXlB20CcmFVZ Cf3N2u83pUqeKX66U0Q45nc9BdiEacyGsn8uc= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=smtpout; bh=CIcMfwlSsNJkrD kR4paMt0V6VCs=; b=Ca86nPTf1bug/LyAGaXLiF5iCuMqOTdsftybNhowwtFKeS Sr/nl7Im5vloVmDO39KKX70Wy6ZawS3qRoa84+s5fqrazHFPpt2TLbKA/U3vbBRU PL8qeeCW+URcJNCtEDq5tzKdGOW6uCtakkiecTo1rhrkt968Cb0bKUWQkTF/0= X-ME-Sender: X-Sasl-enc: Sq65uIfPvOHyyNeVHJGqG+vY0M9C3hab9cxYzO5beW3L 1486942195 Received: from aither.local (unknown [76.25.4.24]) by mail.messagingengine.com (Postfix) with ESMTPA id DDC247E06B; Sun, 12 Feb 2017 18:29:54 -0500 (EST) To: "precis@ietf.org" From: Peter Saint-Andre Message-ID: Date: Sun, 12 Feb 2017 16:29:54 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [precis] names and usernames X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2017 23:29:57 -0000 John Klensin has brought to my attention that it is currently impossible to represent some people's names in PRECIS usernames because some of the relevant Unicode code points are disallowed by the IdentifierClass defined in RFC 7564 (and thus by the UsernameCaseMapped and UsernameCasePreserved profiles defined in RFC 7613). First, RFC 7564 disallows "default ignorable" code points in the IdentifierClass. However, as I understand it some of these code points are need to represent characters in names that might be desirable to people living within communities that use Indic script and eastern Arabic script (e.g., Persian and writing systems derived from Persian). In particular, the Unicode Standard specifies that ZWJ and ZWNJ are "default ignorable" and it seems that these code points are especially important in this context. Second, apparently some Chinese family names are typically written (especially outside the People's Republic of China) using characters that the Unicode Consortium assigns to non-BMP code points, or assigns in the BMP but as compatibility decomposable characters (and thus disallowed by RFC 7564 in the IdentifierClass). I'm not sure whether we can solve these problems (internationalization is messy and we've never tried to guarantee that any particular name or preferred string could be represented in PRECIS usernames), but input from people with a deeper understanding of these issues would be appreciated. I have attempted to reach out to relevant experts, and will report back to this list with any findings. In the meantime, I plan to submit revised I-Ds addressing other issues with the PRECIS specifications sometime this evening. Peter From nobody Sun Feb 12 15:43:36 2017 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF9DC129472 for ; Sun, 12 Feb 2017 15:43:35 -0800 (PST) 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, RP_MATCHES_RCVD=-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 iCtPo_xD_jkS for ; Sun, 12 Feb 2017 15:43:34 -0800 (PST) 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 4175C120726 for ; Sun, 12 Feb 2017 15:43:34 -0800 (PST) Received: from [198.252.137.70] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1cd3no-000BBT-17; Sun, 12 Feb 2017 18:43:32 -0500 Date: Sun, 12 Feb 2017 18:43:24 -0500 From: John C Klensin To: Peter Saint-Andre , precis@ietf.org Message-ID: <2F562E0E75615D28FB8474A8@PSB> 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.70 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [precis] names and usernames X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2017 23:43:36 -0000 Peter, Just to be clear to you and the WG, I don't have a strong opinion about what decision the WG should make in these cases, but I do believe the decision must be explicit and the result of discussion, not something that happens as an accident without knowledge of the relevant cases. best, john --On Sunday, February 12, 2017 16:29 -0700 Peter Saint-Andre wrote: > John Klensin has brought to my attention that it is currently > impossible to represent some people's names in PRECIS > usernames because some of the relevant Unicode code points are > disallowed by the IdentifierClass defined in RFC 7564 (and > thus by the UsernameCaseMapped and UsernameCasePreserved > profiles defined in RFC 7613). > > First, RFC 7564 disallows "default ignorable" code points in > the IdentifierClass. However, as I understand it some of these > code points are need to represent characters in names that > might be desirable to people living within communities that > use Indic script and eastern Arabic script (e.g., Persian and > writing systems derived from Persian). In particular, the > Unicode Standard specifies that ZWJ and ZWNJ are "default > ignorable" and it seems that these code points are especially > important in this context. > > Second, apparently some Chinese family names are typically > written (especially outside the People's Republic of China) > using characters that the Unicode Consortium assigns to > non-BMP code points, or assigns in the BMP but as > compatibility decomposable characters (and thus disallowed by > RFC 7564 in the IdentifierClass). > > I'm not sure whether we can solve these problems > (internationalization is messy and we've never tried to > guarantee that any particular name or preferred string could > be represented in PRECIS usernames), but input from people > with a deeper understanding of these issues would be > appreciated. I have attempted to reach out to relevant > experts, and will report back to this list with any findings. > > In the meantime, I plan to submit revised I-Ds addressing > other issues with the PRECIS specifications sometime this > evening. > > Peter > > _______________________________________________ > precis mailing list > precis@ietf.org > https://www.ietf.org/mailman/listinfo/precis From nobody Sun Feb 12 15:54:48 2017 Return-Path: X-Original-To: precis@ietf.org Delivered-To: precis@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 510C8120726; Sun, 12 Feb 2017 15:54:43 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148694368332.6274.624736054763256562.idtracker@ietfa.amsl.com> Date: Sun, 12 Feb 2017 15:54:43 -0800 Archived-At: Cc: precis@ietf.org Subject: [precis] I-D Action: draft-ietf-precis-7564bis-05.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.17 List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2017 23:54:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Preparation and Comparison of Internationalized Strings of the IETF. Title : PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols Authors : Peter Saint-Andre Marc Blanchet Filename : draft-ietf-precis-7564bis-05.txt Pages : 41 Date : 2017-02-12 Abstract: Application protocols using Unicode code points in protocol strings need to properly handle such strings in order to enforce internationalization rules for strings placed in various protocol slots (such as addresses and identifiers) and to perform valid comparison operations (e.g., for purposes of authentication or authorization). This document defines a framework enabling application protocols to perform the preparation, enforcement, and comparison of internationalized strings ("PRECIS") in a way that depends on the properties of Unicode code points and thus is more agile with respect to versions of Unicode. As a result, this framework provides a more sustainable approach to the handling of internationalized strings than the previous framework, known as Stringprep (RFC 3454). This document obsoletes RFC 7564. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-precis-7564bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-precis-7564bis-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-precis-7564bis-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Feb 12 15:55:06 2017 Return-Path: X-Original-To: precis@ietf.org Delivered-To: precis@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F9FB1294AC; Sun, 12 Feb 2017 15:55:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148694370151.6295.3571565119594590620.idtracker@ietfa.amsl.com> Date: Sun, 12 Feb 2017 15:55:01 -0800 Archived-At: Cc: precis@ietf.org Subject: [precis] I-D Action: draft-ietf-precis-7613bis-05.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.17 List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2017 23:55:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Preparation and Comparison of Internationalized Strings of the IETF. Title : Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords Authors : Peter Saint-Andre Alexey Melnikov Filename : draft-ietf-precis-7613bis-05.txt Pages : 24 Date : 2017-02-12 Abstract: This document describes updated methods for handling Unicode strings representing usernames and passwords. The previous approach was known as SASLprep (RFC 4013) and was based on stringprep (RFC 3454). The methods specified in this document provide a more sustainable approach to the handling of internationalized usernames and passwords. The preparation, enforcement, and comparison of internationalized strings (PRECIS) framework, RFC 7564, obsoletes RFC 3454, and this document obsoletes RFC 7613. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-precis-7613bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-precis-7613bis-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-precis-7613bis-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Feb 12 15:55:38 2017 Return-Path: X-Original-To: precis@ietf.org Delivered-To: precis@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 787ED1294C4; Sun, 12 Feb 2017 15:55:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148694373348.6347.8922453574016627403.idtracker@ietfa.amsl.com> Date: Sun, 12 Feb 2017 15:55:33 -0800 Archived-At: Cc: precis@ietf.org Subject: [precis] I-D Action: draft-ietf-precis-7700bis-05.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.17 List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2017 23:55:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Preparation and Comparison of Internationalized Strings of the IETF. Title : Preparation, Enforcement, and Comparison of Internationalized Strings Representing Nicknames Author : Peter Saint-Andre Filename : draft-ietf-precis-7700bis-05.txt Pages : 11 Date : 2017-02-12 Abstract: This document describes methods for handling Unicode strings representing memorable, human-friendly names (called "nicknames", "display names", or "petnames") for people, devices, accounts, websites, and other entities. This document obsoletes RFC 7700. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-precis-7700bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-precis-7700bis-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-precis-7700bis-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Feb 12 16:02:35 2017 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BC6C129486 for ; Sun, 12 Feb 2017 16:02:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=stpeter.im header.b=uccgEO76; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=V0rEEXEb 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 5ZqiZbo90Y_K for ; Sun, 12 Feb 2017 16:02:32 -0800 (PST) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49A5D120726 for ; Sun, 12 Feb 2017 16:02:32 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailnew.nyi.internal (Postfix) with ESMTP id 9B6BE13A4; Sun, 12 Feb 2017 19:02:31 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Sun, 12 Feb 2017 19:02:31 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=stpeter.im; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=fRBXonyFkDQGk0s rPOEARgU197M=; b=uccgEO76uvnB4LgPfgw8htyV6icMkusKvarvZ6vNVR7e9mR EV90bpMHzsU7tvg9RGh9y1XXpop0GNln5S92rCY4APHyAKNyW+FnSHNvoALsZkSU oLi5H6jY9zfdnQW6TfuKCWvt7jZ0L83wvluBOKuLGQE8Am+tq5Bdavl4Z35Q= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= smtpout; bh=fRBXonyFkDQGk0srPOEARgU197M=; b=V0rEEXEbyOiqJQv4/Etm uVzs6qrM+FQ1aPU9XRfKIouxy3DcpteMWWFoGsdFw5vivKGlqNHD2p5OT0KdQd2r dUm53XYdaLClcX+HquC9aIzgChsmyOaMP8DM57Z7kkV0MK0OXa2rqFK0QsTrbKKL ioG6OweCUX0kHE9Cz7AUEr4= X-ME-Sender: X-Sasl-enc: r0cHKAgzLqw94goTs44uAashWNpjmykH12M8wvFEJB0v 1486944151 Received: from aither.local (unknown [76.25.4.24]) by mail.messagingengine.com (Postfix) with ESMTPA id DBE0A7E2E6; Sun, 12 Feb 2017 19:02:30 -0500 (EST) To: John C Klensin , precis@ietf.org References: <2F562E0E75615D28FB8474A8@PSB> From: Peter Saint-Andre Message-ID: <99d2966a-8cbd-4432-d559-689d6f51d40d@stpeter.im> Date: Sun, 12 Feb 2017 17:02:30 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <2F562E0E75615D28FB8474A8@PSB> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [precis] names and usernames X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 00:02:34 -0000 Agreed. I'm trying to get input from relevant experts, because I strongly doubt that we have the relevant expertise within the WG. Peter On 2/12/17 4:43 PM, John C Klensin wrote: > Peter, > > Just to be clear to you and the WG, I don't have a strong > opinion about what decision the WG should make in these cases, > but I do believe the decision must be explicit and the result of > discussion, not something that happens as an accident without > knowledge of the relevant cases. > > best, > john > > > --On Sunday, February 12, 2017 16:29 -0700 Peter Saint-Andre > wrote: > >> John Klensin has brought to my attention that it is currently >> impossible to represent some people's names in PRECIS >> usernames because some of the relevant Unicode code points are >> disallowed by the IdentifierClass defined in RFC 7564 (and >> thus by the UsernameCaseMapped and UsernameCasePreserved >> profiles defined in RFC 7613). >> >> First, RFC 7564 disallows "default ignorable" code points in >> the IdentifierClass. However, as I understand it some of these >> code points are need to represent characters in names that >> might be desirable to people living within communities that >> use Indic script and eastern Arabic script (e.g., Persian and >> writing systems derived from Persian). In particular, the >> Unicode Standard specifies that ZWJ and ZWNJ are "default >> ignorable" and it seems that these code points are especially >> important in this context. >> >> Second, apparently some Chinese family names are typically >> written (especially outside the People's Republic of China) >> using characters that the Unicode Consortium assigns to >> non-BMP code points, or assigns in the BMP but as >> compatibility decomposable characters (and thus disallowed by >> RFC 7564 in the IdentifierClass). >> >> I'm not sure whether we can solve these problems >> (internationalization is messy and we've never tried to >> guarantee that any particular name or preferred string could >> be represented in PRECIS usernames), but input from people >> with a deeper understanding of these issues would be >> appreciated. I have attempted to reach out to relevant >> experts, and will report back to this list with any findings. >> >> In the meantime, I plan to submit revised I-Ds addressing >> other issues with the PRECIS specifications sometime this >> evening. >> >> Peter >> >> _______________________________________________ >> precis mailing list >> precis@ietf.org >> https://www.ietf.org/mailman/listinfo/precis From nobody Sun Feb 12 19:15:52 2017 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEDBC1294D1 for ; Sun, 12 Feb 2017 19:15:50 -0800 (PST) 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, RP_MATCHES_RCVD=-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 6O88pBv_ZnLL for ; Sun, 12 Feb 2017 19:15:48 -0800 (PST) Received: from babelmonkeys.de (babelmonkeys.de [IPv6:2a02:d40:3:1:10a1:5eff:fe52:509]) by ietfa.amsl.com (Postfix) with ESMTP id BA04B1295AC for ; Sun, 12 Feb 2017 19:15:48 -0800 (PST) Received: from [IPv6:2001:4dd7:a6be:0:39a4:2f97:dca8:a13f] (2001-4dd7-a6be-0-39a4-2f97-dca8-a13f.ipv6dyn.netcologne.de [IPv6:2001:4dd7:a6be:0:39a4:2f97:dca8:a13f]) by babelmonkeys.de (Postfix) with ESMTPSA id A3F861021AF5B for ; Mon, 13 Feb 2017 04:15:47 +0100 (CET) To: precis@ietf.org References: From: Florian Zeitz Message-ID: <71999dc4-b6a3-d949-9432-4ed8ee591967@babelmonkeys.de> Date: Mon, 13 Feb 2017 04:15:31 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [precis] names and usernames X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 03:15:51 -0000 Am 13.02.2017 um 00:29 schrieb Peter Saint-Andre: > John Klensin has brought to my attention that it is currently impossible > to represent some people's names in PRECIS usernames because some of the > relevant Unicode code points are disallowed by the IdentifierClass > defined in RFC 7564 (and thus by the UsernameCaseMapped and > UsernameCasePreserved profiles defined in RFC 7613). > > First, RFC 7564 disallows "default ignorable" code points in the > IdentifierClass. However, as I understand it some of these code points > are need to represent characters in names that might be desirable to > people living within communities that use Indic script and eastern > Arabic script (e.g., Persian and writing systems derived from Persian). > In particular, the Unicode Standard specifies that ZWJ and ZWNJ are > "default ignorable" and it seems that these code points are especially > important in this context. > I'd have to look at it in more detail, but that assessment seems wrong to me. Algorithmically we check for JoinControl before PrecisIgnorableProperties, making ZWJ and ZWNJ CONTEXTJ. That allows them to occur after virama and where they break a cursive connections. I'm not sure those are the only cases that John is concerned about, but they are not generally disallowed as I understand it. That said, I always found it a bit unsettling that it is virtually impossible to determine the algorithmic result from the textual description of what is and isn't allowed. Regards, Florian Zeitz From nobody Sun Feb 12 23:05:03 2017 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06CCC126FDC for ; Sun, 12 Feb 2017 23:05:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 SK1bzjoXR3ft for ; Sun, 12 Feb 2017 23:05:00 -0800 (PST) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (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 85BB412941A for ; Sun, 12 Feb 2017 23:05:00 -0800 (PST) Received: by mail-it0-x22e.google.com with SMTP id 203so176037982ith.0 for ; Sun, 12 Feb 2017 23:05:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3Me02TBzL2Hv4wsioi0TI+TYWdJwtwGn1wLcsvCKA8k=; b=V02t6NW9/iPF+Ifv6SzdELHC5l1EpjjOsHtGAE7AJ2JEG9Vs9AV9ErO/GtjW+LdFH4 P7vVrzeNM9FcbBXnlHGC+Q6zo1uGuZRTrQrX7m/JYCrmnlWyc9gTIAIymf9VF+Ueck1g 3/fSsjKap0nT9CNpJfVQfDavDHt8HUmD3/Qkp4I4RPY6HEz2JYmQX8+VJ1ANDGK1J8rV JIwp3Nk2qNIK+3y8blOXL2dWdt/VGdR/7W9mO+nIaY3XFBwpFh0Mkr0wcdlLS4mXSmoa OW9m3c3adiDmp3L7Rrb2O2jK8Da7CZZJ8KZIhStXaZPLF0nad3V1t92ggLHwzLiC8REg iV4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3Me02TBzL2Hv4wsioi0TI+TYWdJwtwGn1wLcsvCKA8k=; b=WRnZuP5nYMZdPTvzXC5ap9BWo6BWoH76A3isUl1n5EvttGavrz0TJfseFrhUX/xlQs qhWNwhltJJtoNAegPjj0zrSvr1/C5Hrb7uJa+hPVpnrgw0rauRHxpFJfdUdsSD6MFVX4 nNxQ3A9a5iYy3WBHlHnKwSH/FH1fwNM3XiBOupSQqPzShVRH1Dx97qqqkBXcin8pdS31 wVmswG0+bpgsXKkTYutPHA1tmaiJHAQwv8GiNw4GJym41LuvQyRa3VaYEhKKfr4kurKY 0jjCjXLPql8Iwvi4wzU6XDm7U5HSwX8Y79IAn79vxnmCmw55Fi+B9CGE+X3x5qulHDJn XEjw== X-Gm-Message-State: AMke39mDAZv0MLkeCA7K6iaAB9GFRVjMDyeLuDZfHkks36Tm6o2f///FEKuV8on4dXgsxZmhu6Odredsh4MCnQ== X-Received: by 10.36.207.212 with SMTP id y203mr19360500itf.63.1486969499777; Sun, 12 Feb 2017 23:04:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.136.68 with HTTP; Sun, 12 Feb 2017 23:04:59 -0800 (PST) In-Reply-To: <15c31273-c278-af61-2a01-0b68ab8af182@stpeter.im> References: <15c31273-c278-af61-2a01-0b68ab8af182@stpeter.im> From: William Fisher Date: Mon, 13 Feb 2017 00:04:59 -0700 Message-ID: To: Peter Saint-Andre Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: precis@ietf.org Subject: Re: [precis] Enforcement as an Idempotent operation X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 07:05:02 -0000 On Sun, Feb 12, 2017 at 12:27 PM, Peter Saint-Andre wrote: > Did you mean U+212A (KELVIN SIGN)? That decomposes to U+004B (LATIN CAPITAL > LETTER K). > >> The full example is: >> "\U0001f11aevin" => "(K)evin" => "(k)evin" I'm talking about 'PARENTHESIZED LATIN CAPITAL LETTER K' (U+1F11A). Sorry it's not clear that the A is part of the unicode escape. With casefold or tolower, the result is the same for these Nicknames: Not idempotent: "\U0001f11A" => "(K)" => "(k)" Not idempotent: "\U0001f13A" => "K" => "k" Not idempotent: "\u210c" => "H" => "h" Not idempotent: "\u210d" => "H" => "h" Not idempotent: "\u20a8" => "Rs" => "rs" When you apply the comparison steps from RFC 7700, Section 2.4, you still get something that is upper case. If you apply the comparison steps again, you now get lower case. >> I wrote a program to categorize characters that are not idempotent >> under Nickname "ToLower" (ignoring white space). The numbers are the >> same for Unicode 6.3, 8.0 and 9.0. >> >> { >> '': 467, >> '': 90, >> '': 35, >> '': 27, >> '': 4 >> } > > > Would you mind sending me your list of characters? I will send it to you in a separate email. Thanks, Bill From nobody Sun Feb 26 15:32:35 2017 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DC6C1295C8 for ; Sun, 26 Feb 2017 15:32:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=stpeter.im header.b=fIxLdmK0; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=KBtil2Vq 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 zrx7QWSPiV1n for ; Sun, 26 Feb 2017 15:32:32 -0800 (PST) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A70A129516 for ; Sun, 26 Feb 2017 15:32:31 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailnew.nyi.internal (Postfix) with ESMTP id 5B7389D4B; Sun, 26 Feb 2017 18:32:30 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Sun, 26 Feb 2017 18:32:30 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=stpeter.im; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=TORnEcKil5k8fq8 DywRdphr/IwE=; b=fIxLdmK0D82ccLgfSXDeYxnxYrlkzE2hK/UxOfjM2PXzavt QkNqqxBvcNB1gcmE8LXA9BBcek0yhrC6b+Brrc8aBMw+PXdzDLgi0naDfF+X4acS /SEIpk4SaTctYHLa0tIATv2p08ct3s7JXbt2/t9qiEC55VE8LpJQjVwO3ud8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= smtpout; bh=TORnEcKil5k8fq8DywRdphr/IwE=; b=KBtil2VqzcM1yWLsAPjM 74wgO3run4a/Ur69qdH8C833TLTEcBGZW7jPRx28i8XytzFOYIAfU2f5Ld/I3Ebw YqQtPe88TXx8a1NWtcwbgO9eqkbgnkpZfgVduQ/70BcfM6psDg/YvwlvxPeRqjaT +M9Fvqu4W4nzZ0OaAcWIV08= X-ME-Sender: X-Sasl-enc: MqZyr9lNBcJLFeFRIPT80Eq0/T2gPIJM7ypOcZdUgEnO 1488151949 Received: from aither.local (unknown [76.25.4.24]) by mail.messagingengine.com (Postfix) with ESMTPA id 92FBE7E070; Sun, 26 Feb 2017 18:32:29 -0500 (EST) To: Florian Zeitz , precis@ietf.org References: <71999dc4-b6a3-d949-9432-4ed8ee591967@babelmonkeys.de> From: Peter Saint-Andre Message-ID: <00027ab2-0792-6f31-30ce-cf43f60c830a@stpeter.im> Date: Sun, 26 Feb 2017 16:32:28 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <71999dc4-b6a3-d949-9432-4ed8ee591967@babelmonkeys.de> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [precis] names and usernames X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Feb 2017 23:32:33 -0000 On 2/12/17 8:15 PM, Florian Zeitz wrote: > Am 13.02.2017 um 00:29 schrieb Peter Saint-Andre: >> John Klensin has brought to my attention that it is currently impossible >> to represent some people's names in PRECIS usernames because some of the >> relevant Unicode code points are disallowed by the IdentifierClass >> defined in RFC 7564 (and thus by the UsernameCaseMapped and >> UsernameCasePreserved profiles defined in RFC 7613). >> >> First, RFC 7564 disallows "default ignorable" code points in the >> IdentifierClass. However, as I understand it some of these code points >> are need to represent characters in names that might be desirable to >> people living within communities that use Indic script and eastern >> Arabic script (e.g., Persian and writing systems derived from Persian). >> In particular, the Unicode Standard specifies that ZWJ and ZWNJ are >> "default ignorable" and it seems that these code points are especially >> important in this context. >> > I'd have to look at it in more detail, but that assessment seems wrong > to me. > Algorithmically we check for JoinControl before > PrecisIgnorableProperties, making ZWJ and ZWNJ CONTEXTJ. > That allows them to occur after virama and where they break a cursive > connections. Correct. > I'm not sure those are the only cases that John is > concerned about, but they are not generally disallowed as I understand it. Because I don't have a good understanding of the relevant scripts and languages, I am dependent on people who do, such as Nalini Elkins. I shall ping her again to see if she can share her insights. > That said, I always found it a bit unsettling that it is virtually > impossible to determine the algorithmic result from the textual > description of what is and isn't allowed. There is much that is unsettling about internationalization. We do the best we can with what is given. Peter From nobody Sun Feb 26 16:21:46 2017 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD261299C2 for ; Sun, 26 Feb 2017 16:21:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=stpeter.im header.b=WkEv49TG; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=Bu1zX16o 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 lEIAqAH2LWzL for ; Sun, 26 Feb 2017 16:21:44 -0800 (PST) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FE931299C1 for ; Sun, 26 Feb 2017 16:21:44 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailnew.nyi.internal (Postfix) with ESMTP id D9FD49E53; Sun, 26 Feb 2017 19:21:43 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Sun, 26 Feb 2017 19:21:43 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=stpeter.im; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=AaUQhtI85mb0EQU P8+Co3rNKZ6k=; b=WkEv49TGg/DHW76nA+Ro/kwmQ8X6Mlm2VDTqoJf22Ue7LiO I++BwHojeGzLAvgtyvXiZx+usF+wxytLI20j3ntuET6XvpQ5ecdwtmLeakxA2jzV J8RAvmp31Aumn8oJGuE2TaU/pz8BO7jxVqZu/uPZ5kCjBKvU0icGkEpZ0fM4= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= smtpout; bh=AaUQhtI85mb0EQUP8+Co3rNKZ6k=; b=Bu1zX16on6F2PtTfnp9R hL196U9OjlI9d5AoUedKE+RLrnQpZlrqXYLqZ45TVuOKo9em8zhR9Z88b9VfN7JR r2vxuD8oCsOcRZQJiIZJW8YNb6QUjG8Ok2+emxZzUGuxB+MeXQxYiUhaLAg7QWEI hJ8Py7JJFh+y0I01kZtfFh0= X-ME-Sender: X-Sasl-enc: lb+n+cXywX5NtjB8YEMlGjHMIsofcDz/EQ3pQF4QSofq 1488154903 Received: from aither.local (unknown [76.25.4.24]) by mail.messagingengine.com (Postfix) with ESMTPA id 48D107E15C; Sun, 26 Feb 2017 19:21:43 -0500 (EST) To: John C Klensin , precis@ietf.org References: <2F562E0E75615D28FB8474A8@PSB> <99d2966a-8cbd-4432-d559-689d6f51d40d@stpeter.im> From: Peter Saint-Andre Message-ID: <2d231d2b-545c-4c42-e973-8a32f55d1469@stpeter.im> Date: Sun, 26 Feb 2017 17:21:42 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <99d2966a-8cbd-4432-d559-689d6f51d40d@stpeter.im> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [precis] names and usernames X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 00:21:45 -0000 I'm still waiting to hear from experts with knowledge of Indic and eastern Arabic scripts. However, I have been corresponding offlist with someone who has knowledge of the second issue I raised... >>> Second, apparently some Chinese family names According to my correspondent, the challenge is representation of some given names, not family names (e.g., legislation in Taiwan stipulates that a given name can include any character that has ever appeared in a dictionary, even dictionaries published hundreds of years ago). >>> are typically >>> written (especially outside the People's Republic of China) >>> using characters that the Unicode Consortium assigns to >>> non-BMP code points John, forgive my ignorance, but it seems to me that the plane is irrelevant here: in PRECIS we base decisions on code point properties. Thus, for instance, any code point whose Unicode general category is "Lo" (other letter) is allowed in the PRECIS IdentifierClass (per Section 9.1 of RFC 7564), regardless of the plane. As an example, a code point like U+2F804 (CJK COMPATIBILITY IDEOGRAPH-2F804) would be allowed, even though it is in the Supplementary Ideographic Plane. >>> or assigns in the BMP but as >>> compatibility decomposable characters (and thus disallowed by >>> RFC 7564 in the IdentifierClass). My correspondent said it should be fine to disallow compatibility decomposable characters such as U+328A (CIRCLED IDEOGRAPH MOON) because according to him they would not be used in given or family names. All of this is second-hand, so take it with a grain of salt. Peter From nobody Sun Feb 26 16:43:00 2017 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FE10129A22 for ; Sun, 26 Feb 2017 16:42:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=stpeter.im header.b=x/Z9xPIh; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=slZS1Chv 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 Qu-qlAbfmM1p for ; Sun, 26 Feb 2017 16:42:58 -0800 (PST) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 270B2129A20 for ; Sun, 26 Feb 2017 16:42:58 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailnew.nyi.internal (Postfix) with ESMTP id 7992DA722; Sun, 26 Feb 2017 19:42:57 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Sun, 26 Feb 2017 19:42:57 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=stpeter.im; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=LOJHizvjOPt8+87 2DvEKX4wGJog=; b=x/Z9xPIh30w/oKlNCrceY9ClfsW/XQzVbpPgoKtas/QbLcw kD7j/0XeqajTXL4K/dOcdytb2xStQydvmW+eoy51gfcQfffNi3JAKX+3iDjwchDQ 0VzLsG+Xn/MMBGxUGTHO+JWDfWgT88r4PM065x62XtZIEq3rJNiGIYdn2rbg= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= smtpout; bh=LOJHizvjOPt8+872DvEKX4wGJog=; b=slZS1Chv7pcI3jt2sO6c bmhLOjZr3Z1qJGqX0dZEjQ1rPpNCUrYQGBulri1WNPDHVkyBmwF+XwexmeJ2hsKk YJ38gJgOjYmUTHg7k+/jSjGToFPxZHzM5UPERuQ58G1J0dDliaoHl1LRk9UEYzZ/ iN8DWsBTQVAmrDtYlA7vWqQ= X-ME-Sender: X-Sasl-enc: U2j62cz/eJfHpsK3HZGKqaQ108rWNpSh7bhhSOzEM4vA 1488156177 Received: from aither.local (unknown [76.25.4.24]) by mail.messagingengine.com (Postfix) with ESMTPA id CB12A240A5; Sun, 26 Feb 2017 19:42:56 -0500 (EST) To: John C Klensin , precis@ietf.org References: <2F562E0E75615D28FB8474A8@PSB> From: Peter Saint-Andre Message-ID: <23b776e4-198e-7f3a-cb58-b69db52b79d2@stpeter.im> Date: Sun, 26 Feb 2017 17:42:55 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <2F562E0E75615D28FB8474A8@PSB> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [precis] names and usernames X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 00:42:59 -0000 On 2/12/17 4:43 PM, John C Klensin wrote: > Peter, > > Just to be clear to you and the WG, I don't have a strong > opinion about what decision the WG should make in these cases, > but I do believe the decision must be explicit and the result of > discussion, not something that happens as an accident without > knowledge of the relevant cases. As I've been pondering these issues, I've realized we can't guarantee that a user identifier can be (or include) someone's name. Although that might be a desirable property, a username is, after all, an account identifier. There is long precedent (e.g., in email) for allowing a smaller subset of characters in account identifiers than in display names. Thus I suggest that we add a paragraph like the following to 7613bis: A "username" or "user identifier" is a string of characters designating an account on a computing device or system, often but not necessarily for use by a person. Although some devices and system might allow a username to be part or all of a person's name, and a person might want their account designator to be part or all of their name, because of the complexities involved that outcome is not guaranteed for all human names on all computing devices or systems that follow the rules defined in this specification. Protocol designers and application developers who wish to allow a wider range of characters are encouraged to consider a separation between more restrictive account identifiers and more expressive display names. Peter From nobody Sun Feb 26 16:48:49 2017 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13B4C12957F for ; Sun, 26 Feb 2017 16:48:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=stpeter.im header.b=OThVP5bT; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=L4xb/fND 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 PE30SOQTNV2p for ; Sun, 26 Feb 2017 16:48:47 -0800 (PST) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DABF129494 for ; Sun, 26 Feb 2017 16:48:47 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailnew.nyi.internal (Postfix) with ESMTP id 8924FA8E8; Sun, 26 Feb 2017 19:48:46 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Sun, 26 Feb 2017 19:48:46 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=stpeter.im; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=bJlWuW3664ZzNAt cw1ZOrr7NxBo=; b=OThVP5bTc1HWB+zq6MUH9hsDutbM/d0p8iACuAcP0NQQQd0 LYlOuYdmeqzLHZ7F5cMPMe1qVzYgiB6q6KQaSOUhQP4GgmMuvpZ5EI/NZDI90DUa aniLSBZif5wk5PN2STr+VUh6xiibsjj8+9TlwPXeGXckBErZalQY7Nsp7958= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= smtpout; bh=bJlWuW3664ZzNAtcw1ZOrr7NxBo=; b=L4xb/fNDUzTjMu2MyX+P +9+BaqfkRgrqF3J/eM/FKiF4T1hpiw//FGUrC99lAdKZ99rnxqT8mBMjh4isKmhX BtsjhHTEAPMoj5T4IQ+FlH4ZuMnJIwxTNoe4PwYuoZ/ipPa5sJqxgRC8UFSVMzyq S2RkvQBpFSSwhCAOpWMjWqA= X-ME-Sender: X-Sasl-enc: uqmckvi5YptvxY1wppdijAT+ya5P4yOeWVsyWVFGMiIi 1488156526 Received: from aither.local (unknown [76.25.4.24]) by mail.messagingengine.com (Postfix) with ESMTPA id D2ACD240CA; Sun, 26 Feb 2017 19:48:45 -0500 (EST) To: William Fisher References: <15c31273-c278-af61-2a01-0b68ab8af182@stpeter.im> From: Peter Saint-Andre Message-ID: <0f5b55f8-5fcb-2a61-435e-7b93d2d8f9e6@stpeter.im> Date: Sun, 26 Feb 2017 17:48:45 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: precis@ietf.org Subject: Re: [precis] Enforcement as an Idempotent operation X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 00:48:48 -0000 On 2/13/17 12:04 AM, William Fisher wrote: > On Sun, Feb 12, 2017 at 12:27 PM, Peter Saint-Andre wrote: >> Did you mean U+212A (KELVIN SIGN)? That decomposes to U+004B (LATIN CAPITAL >> LETTER K). >> >>> The full example is: >>> "\U0001f11aevin" => "(K)evin" => "(k)evin" > > I'm talking about 'PARENTHESIZED LATIN CAPITAL LETTER K' (U+1F11A). > Sorry it's not clear that the A is part of the unicode escape. Thanks for the clarification. > With casefold or tolower, the result is the same for these Nicknames: > > Not idempotent: "\U0001f11A" => "(K)" => "(k)" > Not idempotent: "\U0001f13A" => "K" => "k" > Not idempotent: "\u210c" => "H" => "h" > Not idempotent: "\u210d" => "H" => "h" > Not idempotent: "\u20a8" => "Rs" => "rs" > > When you apply the comparison steps from RFC 7700, Section 2.4, you > still get something that is upper case. If you apply the comparison > steps again, you now get lower case. I see what you mean. I'm now leaning toward moving the case mapping rule after the normalization rule, but first I want to think about the implications for all of the PRECIS profiles (e.g., when using NFC vs. using NFKC). If we go down this road, we will also want to describe the reasoning in Section 5.2.3 of 7564bis. Peter From nobody Sun Feb 26 17:48:08 2017 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EEC81299F4 for ; Sun, 26 Feb 2017 17:48:06 -0800 (PST) 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, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=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 VU0SUqsCKxU8 for ; Sun, 26 Feb 2017 17:48:05 -0800 (PST) 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 30A9B1295A5 for ; Sun, 26 Feb 2017 17:48:05 -0800 (PST) Received: from [198.252.137.70] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1ciA5E-0003AA-I2; Sun, 26 Feb 2017 20:26:36 -0500 Date: Sun, 26 Feb 2017 20:26:30 -0500 From: John C Klensin To: Peter Saint-Andre , precis@ietf.org Message-ID: <6C5D333475A12AEAAC163D59@PSB> In-Reply-To: <2d231d2b-545c-4c42-e973-8a32f55d1469@stpeter.im> References: <2F562E0E75615D28FB8474A8@PSB> <99d2966a-8cbd-4432-d559-689d6f51d40d@stpeter.im> <2d231d2b-545c-4c42-e973-8a32f55d1469@stpeter.im> 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.70 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [precis] names and usernames X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 01:48:06 -0000 --On Sunday, February 26, 2017 17:21 -0700 Peter Saint-Andre wrote: > I'm still waiting to hear from experts with knowledge of Indic > and eastern Arabic scripts. However, I have been corresponding > offlist with someone who has knowledge of the second issue I > raised... > >>>> Second, apparently some Chinese family names > > According to my correspondent, the challenge is representation > of some given names, not family names (e.g., legislation in > Taiwan stipulates that a given name can include any character > that has ever appeared in a dictionary, even dictionaries > published hundreds of years ago). Entirely possible that I misunderstood the precise nature of the problem. From the standpoint of what should be allowed in an identifier that people would expect to reflect their names, whether then name is a family name, a personal name, a tribal or can name, or a patronymic or matronymic whose seem to be me to make little difference. >>>> are typically >>>> written (especially outside the People's Republic of China) >>>> using characters that the Unicode Consortium assigns to >>>> non-BMP code points > > John, forgive my ignorance, but it seems to me that the plane > is irrelevant here: in PRECIS we base decisions on code point > properties. Thus, for instance, any code point whose Unicode > general category is "Lo" (other letter) is allowed in the > PRECIS IdentifierClass (per Section 9.1 of RFC 7564), > regardless of the plane. As an example, a code point like > U+2F804 (CJK COMPATIBILITY IDEOGRAPH-2F804) would be allowed, > even though it is in the Supplementary Ideographic Plane. If I recall, there is another issue with compatibility ideographs (i.e., theu may or may not be a good example), but your statement above should certainly be correct. My reason for mentioning the BMP is that we have recently again heard from someone who wants to confine an I18n library to work in UTF-16, apparently without surrogates. While any problems of that sort would certainly be bugs, that sort of UTF-16 discussion leaves me with the sense that higher planes may be a bit less useful in practice than the BMP. That is not, however, a protocol specification problem in any way. >>>> or assigns in the BMP but as >>>> compatibility decomposable characters (and thus disallowed >>>> by RFC 7564 in the IdentifierClass). > My correspondent said it should be fine to disallow > compatibility decomposable characters such as U+328A (CIRCLED > IDEOGRAPH MOON) because according to him they would not be > used in given or family names. Whether the rules of IDNA2008 are good enough is another matter -- if nothing else, we had to work with the properties Unicode gave us -- but the basic intent was certainly to disallow any code point that, visually and in general understanding, was a circled variation on a base character or a font variation that was not normally considered a different base character > All of this is second-hand, so take it with a grain of salt. FWIW, consistent with my knowledge. john From nobody Sun Feb 26 20:30:30 2017 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A4E01296F2 for ; Sun, 26 Feb 2017 20:30:28 -0800 (PST) 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 0sTn4X71G1CE for ; Sun, 26 Feb 2017 20:30:25 -0800 (PST) Received: from JPN01-TY1-obe.outbound.protection.outlook.com (mail-ty1jpn01on0097.outbound.protection.outlook.com [104.47.93.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CA7C127058 for ; Sun, 26 Feb 2017 20:30:25 -0800 (PST) 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=6BngpOige7wjSn/AwrEQBE1Set9de3o2D9weroDJrdQ=; b=LnzFX5mrlP3AnpfJds2bWMmivC3pBaLwgL+5nILf0uAxU/+xcGOJH0vE8zw9ChMGa5qOd3U5lCPmLbq9LtMV5sjFDm6T7n+xU657/l9kg7zPuuDufbs4r56RXYsIUnXUVn3VAisjxg4sqwy8iHv6Fx6JSVP5WTl9JtMQAoT5dJ4= 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 TY1PR01MB0652.jpnprd01.prod.outlook.com (10.167.158.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.933.12; Mon, 27 Feb 2017 04:30:21 +0000 To: John C Klensin , Peter Saint-Andre , References: <2F562E0E75615D28FB8474A8@PSB> <99d2966a-8cbd-4432-d559-689d6f51d40d@stpeter.im> <2d231d2b-545c-4c42-e973-8a32f55d1469@stpeter.im> <6C5D333475A12AEAAC163D59@PSB> From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <3d9c5353-17b2-543b-8f5e-93729fdb8793@it.aoyama.ac.jp> Date: Mon, 27 Feb 2017 13:30:18 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <6C5D333475A12AEAAC163D59@PSB> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [133.2.210.64] X-ClientProxiedBy: TY1PR01CA0046.jpnprd01.prod.outlook.com (10.164.162.156) To TY1PR01MB0652.jpnprd01.prod.outlook.com (10.167.158.15) X-MS-Office365-Filtering-Correlation-Id: b220e291-1b52-4bf3-7116-08d45ec957c0 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:TY1PR01MB0652; X-Microsoft-Exchange-Diagnostics: 1; TY1PR01MB0652; 3:6JzjPmZSMe6gvr89YtP1vPQ2j7NhavFQEw3uDUMyPJgWGdzG8abdnlNwCHFCKjtu47lko0VF3ol4AOXssHN2VP17TQkP2gEcF4Itx0I1p36b5OdikGdsU0FHDz/mLi/0t1/3pUmVXfygkIib41Jft+MRNyGOjzEqwGsNvZ3B3U0RLI6Lfa1x0LMnZGJIZy2jO0oFZqW126/90AjnBwzT8AZO9G2bg7Wacc7YhgskKZ7vRQJ9fyuWITFwVx1BaAqqEtGmiwS+z/EloqtiT4AQBQ==; 25:51Pxjx4A9ODA2or9LLuReCG5T6O4EyoVkJCu1mVTsQa2ZwUrWzCgK9hSSrcC+OpGRek8q3LSdH+yYxf3XBHURnQxZiitOaBGoX7Nn9KBkhHm8oKzayJyQ1VY0ENpLFPgZwONjr4c7Q/YU+1EwOmntgfOC/0c1666OshSOKhE5CwSMM526/LupF2IQ5wPCC+5fXvnBGKdKunaKMURBs4vJM8zScd0LgrrkSausxfddhIKczoGYVs8Gp8Kzd6kbSRdyIrFcH9LiDa6PsrLYR08PqH3Cowkx9Or5DeMF1/N0koo0cHurRKSSJaepII4VKMOzut++CCepxA12Ji2UrHX5t8Af/fbEodS6B2udlTSlvrIzJBmXGgmn4X3/lbvW0TI6cRNBbS/W1SKnSbGybW1h1I2FSd3kIacwgDdFwSB3LFp2wNy6K4oSdvvmSdPgD4t1tz86pIS2SJG8Syx8yLHBA== X-Microsoft-Exchange-Diagnostics: 1; TY1PR01MB0652; 31:gQkLcxBvBLxALCccnaf/sPfe/Bk9mz+Gck802+dcoegoT1x7BzTOBTU6fQ+TF+LOuyQ0/MH5+wRCH9l1I/StMwFDp3PSEvX7QUA2ned7kad3ZRKaqQPBcL6AkOl20KfIvyCZ5NS51ZfOgrZ3H+7R/9xIaAmIks7JRg6fRGhX/feJ93zSv5ccNWpovXRQQ4QCf3uDmuyl3xKmq+wmKKP2pw5sqNkAEXeeFyJIxOxt1p+gNocruKiK4qDNgZOGFGh77pOjRJ4ghR/BHoDsZIBm/A==; 4:8BietDMNrPC4Mw8olQqJN0C7CayE6xf0cITHbCcuRcJHTltvGz2mA5RGGEHeP5gIKNYlGJ7m9FMYmrO/uyiI3f+sqFbleg/0fVbp6f+e+lwoh5z0f4SAuDeU0C1JhiOUVVyxrMS2tlGQxCuL3AsFVzg97Fdvpxq4DOX3tB2pLtmpEZDwvGgVoPf+qorkRZzup5bEZY9q7J10Bj32T1dNrMVdYRItc9MZYyxNWoSD+0XDmEfgP409IxjVbFYukyr118J5oXORY4WDUhLYIR4tKynr/0tLTftQSwlOmcJNsDy7lM0WwYDg9D5iQVq0istOZ7NW8g4z6I0In6Z3KR1stCsYwRJWNtxOYs8bS0ywrN+oDQu4tIGFkotUdDHFK1/QaL7CnDPNQ4W6dAfMRJK5wGmv43HqQ4ByXSmUkt09HdRejjaUMRVD+F4SmbJy09i8YXXppw79vgg6X++i1ga2+7ts8+hQrD4r3++Gfrn2eSnU3znpkZ4GZrHKyOwzI4w1d4VBV9a9+Nl0oIF9zm9ApnQ3oetiqIsG/XJZtBMVrCCRDd0L2PTfAhZ57yyFYtAS9rIMHmcrcX+4HvKJFsJyd2dVkvrZMsOy+TJqrY4rcIA= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123560025)(20161123555025)(20161123562025)(20161123564025)(20161123558025)(6072148); SRVR:TY1PR01MB0652; BCL:0; PCL:0; RULEID:; SRVR:TY1PR01MB0652; X-Forefront-PRVS: 02318D10FB X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(7916002)(39450400003)(24454002)(189002)(199003)(42882006)(2950100002)(2906002)(189998001)(6306002)(93886004)(86362001)(6666003)(92566002)(53546006)(81156014)(101416001)(305945005)(8676002)(54356999)(76176999)(42186005)(81166006)(50986999)(90366009)(31686004)(25786008)(64126003)(65956001)(229853002)(74482002)(6486002)(66066001)(65806001)(4001350100001)(68736007)(97736004)(47776003)(83506001)(23676002)(5660300001)(53936002)(38730400002)(31696002)(6116002)(3846002)(65826007)(105586002)(50466002)(7736002)(33646002)(966004)(230700001)(106356001)(6246003)(3940600001); DIR:OUT; SFP:1102; SCL:1; SRVR:TY1PR01MB0652; 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?MTtUWTFQUjAxTUIwNjUyOzIzOlYzaG9teWMxaWhxQU9Ka2xKcXRXVkxKWGFU?= =?utf-8?B?QTQrb1M1ZWNzRG5KVDVkQ2FkdEpCR3ZFZUROdDAxYkpzWkZBYXFCQUdmNnFQ?= =?utf-8?B?QkdkbFJWUWx2anVsNGx4SENzUkpqZ2k1TUw2WGt1UVlPMnEvYUVla091ZjJP?= =?utf-8?B?R253NVJ0c1NEWmVnOUcwbUVLVEFxRmwybFJCRnZXOGRCNUhjemxCUE1GdllE?= =?utf-8?B?bnRCQXdNY3greGFjS0trYVV4Z21pTEc3MVJoWjZ5cnl0L1lUSFlKQ2M1NHJr?= =?utf-8?B?Wk51WENIUkY5V2gyWnYxc1R1aVVKVnl3cWNDU3lINWxwcmZPRDM3eDZxZnVC?= =?utf-8?B?bFdpdVRla25DR092dk5GMW5rTnl3bEtOT2ZOU09EUHpBN1hZWGtzd25MTENr?= =?utf-8?B?R2o5bkdrNFF5cnlkWCtURmQrelV4Njc4dHJra0oyVk13VE1pUWN4VHgvS2Rh?= =?utf-8?B?OTRPU28xVDZjRlZhQ3pHclhueWt6eW1CTS9lMTFPelpmeGQzMkFQZjJNOHBk?= =?utf-8?B?VEJZOWtXVkpmeFljR3U2a3JNWlFQVFYzOTJ0Tjl5TmVnNjkxK1FhYWhic3pG?= =?utf-8?B?TXFJZFFpc1kxWktMbWRaZnBLTHFHdGE3czYvTWVXSFVOT2F3S0M0VHRYMmhN?= =?utf-8?B?d3Q1U1hldzJFQTdiVlBzczNEbjNLWWo5M0ZIVEo3WEpxenVrelJTclBFVThS?= =?utf-8?B?eGNraExzcFltaG1GdzdHd0dMRXJlUmZ3NWV0M0lwVXh3MERpdWptbWJzZURI?= =?utf-8?B?Y1JxNzBVd0ZZU21rakdzeCtCeUYwV3RQYlVxL0RlV0dPM3hnaHpPRS9wSXJU?= =?utf-8?B?V3BJMnVrWTYrVERXWHU2dWtaL2hOL05xTWJ6WCtDeHZjdmZIaEYzbGFua0kw?= =?utf-8?B?Q1R0VXF3VTgxT0hnWXEva2EzREJZNkZLMERET1hscnpML09Rc2ltS2ZrVDdn?= =?utf-8?B?a0hrblhDaks1REp0OXEvRFVoRWJwdnhPS3paL2l4bEdsRXVvdC9ld1pzZlVm?= =?utf-8?B?cDRwY1VGUG9VMEh1Rk54U0dhc2ZyTDV1ZHV5YjczdVNVOW1lNDBOWDREYTFW?= =?utf-8?B?UUNTVVU2V3YvNjErUnFMbmQzWk5TOUdhdldqdy9sTXZwcWJ0MC92UTg3WjhI?= =?utf-8?B?WlQ5M1paQklod3p1MU1zdHZ5R3p2NWFkemU4eUF6U0NmendPWWdvSnJsRURx?= =?utf-8?B?R3NKV0xhL01pNXhhM2ppTis3TjRNL2JkNmdLTW5BbTZ2UkNRKzA3dldoYjNz?= =?utf-8?B?ekVId2w5c1paYUxkOGZYMUVRYVVua2MvU1JObDRqRHlCZW9BM1J0c2FjdER5?= =?utf-8?B?aExEN3E2SzRRQW5ndDJhRnZKam16bldCZGo4d1V3cG1KSDJLZTY5L1orYXkz?= =?utf-8?B?V0ptMnBEKzRNM2M4eVhRSjRXVlNmQU9zYzJyeXA3K1ViN0QzSk8xY0J0Mkg3?= =?utf-8?B?K2ZlaDFDNC9XVjBSakNnUmVGWUdCTnd5T1JhUXV1ZVFPenR2REU2eEtib25M?= =?utf-8?B?K1dKeXdBSmtzVjMwbUh4Tm1RY2ZlbDZpL1M2THZLdnpuMDE2N3JUS2JVQzNI?= =?utf-8?B?d05YWUlXcmk0UUk3OFAvU3FKNHJLU0NWMG1oTDZMOU5PMTVhWlBTZzdLOVJ0?= =?utf-8?B?QmlDWHB0aGpjaWprSUwxWUtOdGI3aXY2MXdob3NSbDB0MVhYMVE5b2FWSlRS?= =?utf-8?B?V0hUcmhwbnp3VTRVZ083QmVGL1NOVnFDOUw4TDBSdGMrQ2I5UzBpajVjeUdv?= =?utf-8?B?ZHZySlpPTkhyL1NTQUszQnVURm52SWxMdkVYMXl1RGtxYkxBaXd4OXdaUzNV?= =?utf-8?B?R0xkTmlGSk9FS2NQbDZqUm9hOXpDMVEyN1g0Z25LMGFhejBUdHBFeklpa1dR?= =?utf-8?Q?MCnM/4LCHAYGdnX7luBx/E5HzBG/fjs8?= X-Microsoft-Exchange-Diagnostics: 1; TY1PR01MB0652; 6:0WarJY+AGSrakmES9ako2t/8YlrbbQVJNCWhYxgVI2DPHztkWPbgEFkF2yPXRjS5500pBxBwU4nWxS10RB3vamGDoV0RWqyPXSNNpeTUPr7+uoiVR/izbTZ/fsg10X0yoS6H/mBR0ivOMlO9kji7q+1gKsXMk2kxjq1ifc6pauBphZpqCW6RkMHV+VSlhk3VKcXMZCOIkvmgiVKndwm0YluO6fS74uj48B5vyelgvp0H8wkHpiRDYxK8aIgUf3owtQ2jO5LxWwJ84b79hoYK3CqPrOOIX/vRNQ31lDheZ0D6Kfz0VbbhBDvPluPTirH92aTSNbBG3MqVVFZ8gA88JA7U86RgdrxRI/3Z9MRysXYRXsTY00ih4aCmY8gMFbIuF0zpyaCRTnwcFM7BeB61mA==; 5:cztJfeJQh9CqmN0+7CsldwCdetUiM8wPfd3JtU8D6rnmeSfWi/o6Tn6+fHS8cN1yKvi09czdIocXf0Pd/LfrxLCuAbp+hAyYujHbU9lXGuewIOBCzMbRdbfpGGUo67OUgqVz8/Tj/WjyfzgcOmYpo7STtpXa2XWzbljP98eo/SI=; 24:CpamxLM2C8lz7Whr7JPcSWMsyrLfO9x57KIgV6dpHtnIMij9thSXhX+uPhLxm4w8NA4U1igTO8fi1mJILTpCeYhTTP69K1nfJu/4ftrFkD8= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; TY1PR01MB0652; 7:OLR1A0ZVjEAtbh8KgoXOvWq0QT65nDORbAqSdAiUHPQN4n8qTBsO8mWViSNuNvdGvqmY33zeWBvU7W+exp5ReApfh76z1LBxcBI8hSmEzq/DgpPqrPS6AFkA3lf+vwrE2Yu2POYK22k0tN0xkfkyjXZISoUJQt6y2SX21bSqInqkWSQaI8jdt3rbTKq1SGwOCYvgaHwI6m9RTZKgcE8S54xihqRf4p61ciZKdycwsP2Btu+Ze9f0Clq63RekZ1veZ6qGqPe+w68nPXF9aWSIfreLMMRzhwjcBlscCLj4Seo62kfHZq0Nmi696KhPaxjs2gduxAeg82M3jx3WluDoHA== X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Feb 2017 04:30:21.9280 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY1PR01MB0652 Archived-At: Subject: Re: [precis] names and usernames X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 04:30:28 -0000 On 2017/02/27 10:26, John C Klensin wrote: >>>>> or assigns in the BMP but as >>>>> compatibility decomposable characters (and thus disallowed >>>>> by RFC 7564 in the IdentifierClass). There are many different reasons for a character to have a compatibility decomposition. The oldest Unicode data file, http://www.unicode.org/Public/UCD/latest/ucd/UnicodeData.txt, even contains labels for these. But having looked again through the list of these labels, excluding them seems very appropriate in all cases. >> My correspondent said it should be fine to disallow >> compatibility decomposable characters such as U+328A (CIRCLED >> IDEOGRAPH MOON) because according to him they would not be >> used in given or family names. This would be indeed about as weird as using using circled letters in a Western name. In Unicode, circled moon is followed by circled fire, water,... It's very clear that these are specific 'styles' for the days of the week in Japanese (not in Chinese, don't know about Korean). Regards, Martin.