From yoshiro.yoneya@jprs.co.jp Wed Sep 4 00:26:00 2013 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 2FF0E11E817D for ; Wed, 4 Sep 2013 00:26:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.367 X-Spam-Level: X-Spam-Status: No, score=-102.367 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xlOvEJvvkHJm for ; Wed, 4 Sep 2013 00:25:59 -0700 (PDT) Received: from off-send01.tyo.jprs.co.jp (off-send01.tyo.jprs.co.jp [IPv6:2001:df0:8:17::10]) by ietfa.amsl.com (Postfix) with ESMTP id 7E8E011E8124 for ; Wed, 4 Sep 2013 00:25:58 -0700 (PDT) Received: from off-sendsmg01.tyo.jprs.co.jp (off-sendsmg01.tyo.jprs.co.jp [172.18.8.32]) by off-send01.tyo.jprs.co.jp (8.13.8/8.13.8) with ESMTP id r847PsrG002010 for ; Wed, 4 Sep 2013 16:25:57 +0900 X-AuditID: ac120820-b7f196d00000167f-d1-5226e0859187 Received: from NOTE550 (off-cpu04.tyo.jprs.co.jp [172.18.4.14]) by off-sendsmg01.tyo.jprs.co.jp (Symantec Messaging Gateway) with SMTP id C6.1B.05759.580E6225; Wed, 4 Sep 2013 16:25:57 +0900 (JST) Date: Wed, 4 Sep 2013 16:25:58 +0900 From: Yoshiro YONEYA To: precis@ietf.org Message-Id: <20130904162558.7fad8dd5d2304591166dd37a@jprs.co.jp> In-Reply-To: <20130828154603.a94201dea74f29229b4767b2@jprs.co.jp> References: <20130828154603.a94201dea74f29229b4767b2@jprs.co.jp> X-Mailer: Sylpheed 3.3.0 (GTK+ 2.10.14; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHIsWRmVeSWpSXmKPExsWyRoiFT7f1gVqQwax1Uha7vv9hdWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxsIfDxgLNrJXHJhyibmB8R9rFyMnh4SAicSGxesZIWwxiQv3 1rN1MXJxCAkcZ5Q4/ukkO0iCRUBF4ufERWANbAIGEr+W/WYCsUUEhCVu3V4IFhcWsJOYtWYG M4jNK+AgMWFXL5jNKeAosf7kAzBbCCh+aMYUFohlFhIXmjqA5nMA1QtK/N0hDBJmFtCSePjr FguELS+x/e0c5gmMfLMQqmYhqZqFpGoBI/MqRpn8tDTd4tS8lOLcdANDvZLKfL2sgqJivWQQ vYkRHFwcCjsYZ5wyOMQowMGoxMMb+0Q1SIg1say4MvcQoyQHk5Iob+p9tSAhvqT8lMqMxOKM +KLSnNTiQ4wSHMxKIrwJPkA53pTEyqrUonyYlDQHi5I47/E/ZwKFBNITS1KzU1MLUotgsjIc HEoSvMYgQwWLUtNTK9Iyc0oQ0kwcnCDDeYCGy4DU8BYXJOYWZ6ZD5E8xSkqJ8xqBJARAEhml eXC9rxjFgV4Q5lUCyfIAEwVc1yuggUxAA9M+q4IMLElESEk1MLIcDJtYusPMQzEgbZrXpNjj t7525usnW1/608PtfpJLZN2k1eeL9LJjxE49q+vd2M3d5R07P3ebaPmVsiZW1pViZ7xriz25 tpo57vsl5FdRnLpjiv2090eLLwjz1DgkZR+XZfhftnvlaYE/i6a/ZV9Sf6bOf+/jIyK165O9 TeefKTc9WfZ7hhJLcUaioRZzUXEiAFoDvovRAgAA Subject: Re: [precis] WGLC: draft-ietf-precis-framework-09.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 07:26:00 -0000 Dear all, This is reminder. WG LC will end next week. Please review the document and give your feedback. Regards, -- Marc & Yoneya, co-chairs On Wed, 28 Aug 2013 15:46:03 +0900 Yoshiro YONEYA wrote: > Dear all, > > This message starts two weeks Working Group Last Call (WGLC) on > draft-ietf-precis-framework-09.txt (PRECIS Framework: Preparation and > Comparison of Internationalized Strings in Application Protocols). > > Please review the document and send comments to the list (precis@ietf.org), > the co-chairs (precis-chairs@tools.ietf.org), or the authors > (draft-ietf-precis-framework@tools.ietf.org) by the end of WGLC. > > The WGLC will end on Wednesday, Sep 11th. > > Regards, > > -- Marc & Yoneya, co-chairs > > _______________________________________________ > precis mailing list > precis@ietf.org > https://www.ietf.org/mailman/listinfo/precis > > From yoshiro.yoneya@jprs.co.jp Wed Sep 4 00:26:06 2013 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 7F73911E818A for ; Wed, 4 Sep 2013 00:26:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.413 X-Spam-Level: X-Spam-Status: No, score=-102.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hnzpYArvPN9Q for ; Wed, 4 Sep 2013 00:26:06 -0700 (PDT) Received: from off-send01.tyo.jprs.co.jp (off-send01.tyo.jprs.co.jp [IPv6:2001:df0:8:17::10]) by ietfa.amsl.com (Postfix) with ESMTP id C6C7411E8124 for ; Wed, 4 Sep 2013 00:26:05 -0700 (PDT) Received: from off-sendsmg01.tyo.jprs.co.jp (off-sendsmg01.tyo.jprs.co.jp [172.18.8.32]) by off-send01.tyo.jprs.co.jp (8.13.8/8.13.8) with ESMTP id r847PsrK002010 for ; Wed, 4 Sep 2013 16:26:05 +0900 X-AuditID: ac120820-b7f196d00000167f-d6-5226e08d8f93 Received: from NOTE550 (off-cpu04.tyo.jprs.co.jp [172.18.4.14]) by off-sendsmg01.tyo.jprs.co.jp (Symantec Messaging Gateway) with SMTP id 57.1B.05759.D80E6225; Wed, 4 Sep 2013 16:26:05 +0900 (JST) Date: Wed, 4 Sep 2013 16:26:06 +0900 From: Yoshiro YONEYA To: precis@ietf.org Message-Id: <20130904162606.a9058ca9af33636feb270c7f@jprs.co.jp> In-Reply-To: <20130828154613.9dadcee8c26f16af000854a9@jprs.co.jp> References: <20130828154613.9dadcee8c26f16af000854a9@jprs.co.jp> X-Mailer: Sylpheed 3.3.0 (GTK+ 2.10.14; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLIsWRmVeSWpSXmKPExsWyRoiFT7f3gVqQwYcFAha7vv9hdWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXRuPFy8wF79gqnt25z9zAeIS1i5GTQ0LAROL+i+NsELaYxIV7 64FsLg4hgeOMEgdm3gJLsAioSJx9uwysgU3AQOLXst9MILaIgLDErdsLweLCArYS7cuXs4PY vAIOEpcbd4L1cgo4ShzoesbYxcgBNNRBYvFrK4hdFhIXmjrYQcK8AoISf3cIg4SZBbQkHv66 xQJhy0tsfzuHeQIj3yyEqllIqmYhqVrAyLyKUSY/LU23ODUvpTg33cBQr6QyXy+roKhYLxlE b2IEhxaHwg7GGacMDjEKcDAq8fDGPlENEmJNLCuuzD3EKMnBpCTKm3pfLUiILyk/pTIjsTgj vqg0J7X4EKMEB7OSCG+CD1CONyWxsiq1KB8mJc3BoiTOe/zPmUAhgfTEktTs1NSC1CKYrAwH h5IErzHIUMGi1PTUirTMnBKENBMHJ8hwHqDhMiA1vMUFibnFmekQ+VOMklLivEYgCQGQREZp HlzvK0ZxoBeEeZVAsjzANAHX9QpoIBPQwLTPqiADSxIRUlINjLwFobcSjKM1t+/gfueXI5in cOqAXI991pQ66xneKn+fLGF+7Lrgt4Gq510pB8eNu73+pl5tfj1LIjFySViB4p/zFoq7f9xc cuqSu1xpy2cT6YfM3nNVS492Xdix/3r6vaykvXccrtjGZ1lFPQ9nsLf/8V/k/W+VK9cb24Lb ZjGaeYdf7WGvVmIpzkg01GIuKk4EAIfyWCHQAgAA Subject: Re: [precis] WGLC: draft-ietf-precis-mappings-03.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 07:26:06 -0000 Dear all, This is reminder. WG LC will end next week. Please review the document and give your feedback. Regards, -- Marc & Yoneya, co-chairs On Wed, 28 Aug 2013 15:46:13 +0900 Yoshiro YONEYA wrote: > Dear all, > > This message starts two weeks Working Group Last Call (WGLC) on > draft-ietf-precis-mappings-03.txt (Mapping characters for PRECIS classes). > > Please review the document and send comments to the list (precis@ietf.org), > the co-chairs (precis-chairs@tools.ietf.org), or the authors > (draft-ietf-precis-mappings@tools.ietf.org) by the end of WGLC. > > The WGLC will end on Wednesday, Sep 11th. > > Regards, > > -- Marc & Yoneya, co-chairs > > _______________________________________________ > precis mailing list > precis@ietf.org > https://www.ietf.org/mailman/listinfo/precis > > From stpeter@stpeter.im Wed Sep 4 08:10:10 2013 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 543C911E81C8 for ; Wed, 4 Sep 2013 08:10:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.407 X-Spam-Level: X-Spam-Status: No, score=-102.407 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zIcQADSdBWOl for ; Wed, 4 Sep 2013 08:10:05 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 0298511E81C3 for ; Wed, 4 Sep 2013 08:10:05 -0700 (PDT) Received: from ergon.local (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 7E2EC415E0; Wed, 4 Sep 2013 09:14:10 -0600 (MDT) Message-ID: <52274D4A.4080805@stpeter.im> Date: Wed, 04 Sep 2013 09:10:02 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Yoshiro YONEYA References: <20130828154613.9dadcee8c26f16af000854a9@jprs.co.jp> <20130904162606.a9058ca9af33636feb270c7f@jprs.co.jp> In-Reply-To: <20130904162606.a9058ca9af33636feb270c7f@jprs.co.jp> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: precis@ietf.org Subject: Re: [precis] WGLC: draft-ietf-precis-mappings-03.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 15:10:10 -0000 On 9/4/13 1:26 AM, Yoshiro YONEYA wrote: > Dear all, > > This is reminder. WG LC will end next week. > Please review the document and give your feedback. Thanks for the reminder. In the Introduction, I think this text is slightly misleading: Usually users do not care about the case and/or width of input characters because they appear to be visually identical. I don't think 'A' and 'a' appear to be visually identical; however, users might consider them to be funtionally equivalent. I suggest the following text: Usually users do not care about the case and/or width of input characters because they consider those characters to be visually identical or functionally equivalent. Section 2.3 (on local case mapping) is hard to understand. I will send a separate message about that, because I want to review some of the Unicode documents and data first. Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Wed Sep 4 14:43:31 2013 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 48E9321F9AAE for ; Wed, 4 Sep 2013 14:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.416 X-Spam-Level: X-Spam-Status: No, score=-103.416 tagged_above=-999 required=5 tests=[AWL=1.183, BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FVPyEGrE91P5 for ; Wed, 4 Sep 2013 14:43:26 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 66A0021F9B57 for ; Wed, 4 Sep 2013 14:43:25 -0700 (PDT) Received: from ergon.local (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 71958415DE; Wed, 4 Sep 2013 15:47:30 -0600 (MDT) Message-ID: <5227A979.7050403@stpeter.im> Date: Wed, 04 Sep 2013 15:43:21 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "precis@ietf.org" X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: [precis] local case mapping X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 21:43:31 -0000 As mentioned, I find Section 2.3 of draft-ietf-precis-mappings hard to understand. This message is a bit long because I was puzzling over things as I wrote it. I hope it's not too rambling. A relatively minor point: there's a bit of confusion between locale-dependent mapping and context-dependent mapping. For instance: Local case mapping is case folding that depends on language and context. For example, the mapping of LATIN CAPITAL LETTER I (U+0049) depends on the language context of the user: if the language is Turkish (or one of several other languages), the character should be mapped into LATIN SMALL LETTER DOTLESS I (U+0131) as this character's lower case equivalent. The first sentence is confusing because it says that local case mapping depends on language *and* context. I think we mean language *or* context (or, even better, locale or context, since the Unicode standard talks about "locale-dependent case mapping"). Also, the use of "case folding" might not be quite right here, because that term has a very specific meaning (e.g., Chapter 5.18 of the Unicode standard says things like "The Unicode case folding algorithm is defined to be simpler and more efficient than case mappings."). In the next sentence, the phrase "language context" will cause even more confusion. :-) I think "language" is enough here. Also I think it would be helpful to add an example of a context-dependent mapping (but see below!). Thus I suggest: Local case mapping depends on locale or context. As an example of locale-dependent mapping, LATIN CAPITAL LETTER I (U+0049) is normally mapped to LATIN SMALL LETTER I ((U+0069); however, if the language is Turkish (or one of several other languages), then the character should be mapped to LATIN SMALL LETTER DOTLESS I (U+0131). As an example of context-dependent mapping, GREEK CAPITAL LETTER SIGMA (U+03A3) is mapped to GREEK SMALL LETTER SIGMA (U+03C3) if it is followed by another letter, but is mapped to GREEK SMALL LETTER FINAL SIGMA (U+03C2) if it is not followed by another letter. So that's the first paragraph. :-) The second paragraph says: Local case mapping targets only characters that get two different results to perform just casefolding that is defined in the Casefolding.txt [Casefolding] and perform special casefolding that is defined in the Specialcasing.txt then casefolding, because PRECIS framework have casefolding. (Nit: The file names are actually CamelCase in the UCD, i.e., CaseFolding.txt and SpecialCase.txt.) That's a long sentence. I suggest breaking it up (I started to do that but then bigger questions arose). As I understand it "just casefolding" isn't really defined in the CaseFolding.txt file, because four kinds of casefolding are specified there: (1) common case folding, (2) full case folding, (3) simple case folding, and (4) Turkic mappings for uppercase I and dotted uppercase I. It's not clear to me exactly what draft-ietf-precis-mappings is recommending here. Is it saying that local case mapping applies (a) when there is a difference between common case mapping and anything else, (b) when there is no common case folding, (c) when there are multiple possible case foldings, or (d) something else? As examples: 1. Common case folding handles things like LATIN CAPITAL LETTER A (U+0041) to LATIN SMALL LETTER A (U+0061). There are no alternative mappings for this character and it's handled by UnicodeData.txt. 2. Full case folding can result in mapping to multiple characters, such as LATIN CAPITAL LETTER SHARP S (U+1E9E) to LATIN SMALL LETTER S (U+0073) + LATIN SMALL LETTER S (U+0073). 3. Simple case folding always maps to a single character, such as LATIN CAPITAL LETTER SHARP S (U+1E9E) to LATIN SMALL LETTER SHARP S (U+00DF). (As we see, there are several possible case foldings for U+1E9E.) 4. LATIN CAPITAL LETTER I commonly maps to LATIN SMALL LETTER I but under Turkic mappings it maps to LATIN SMALL LETTER DOTLESS I. The UnicodeData.txt file specifies one-to-one case mappings that are independent of language, locale, and context. Thus it doesn't cover: - full case folding (e.g., in UnicodeData.txt U+1E9E is mapped to U+00DF, not U+0073 U+073) since that's not one-to-one - context-specific mappings such as uppercase Greek sigma to Greek final sigma when followed by a space - locale-specific mappings such as LATIN CAPITAL LETTER I to LATIN SMALL LETTER DOTLESS I in Turkic languages I think we need to be clear about what we're trying to accomplish here. Are we actually addressing all mappings that are not handled by the UnicodeData.txt file (i.e., everything except "common case folding" as specified by the CaseFolding.txt file)? It seems that way to me (i.e., we need to say something about context-specific mappings for sure, and probably also case folding that isn't one-to-one such as LATIN CAPITAL SHARP S to ss), but that's not what draft-ietf-precis-mappings says now... There are two types casefoldings defined as Unconditional Mappings and Conditional Mappings in the Specialcasing.txt file. Conditional mappings have Language-Insensitive Mappings that target characters whose full case mappings do not depend on language, but do depend on context. Language-Sensitive Mappings that these are characters whose full case mappings depend on language and perhaps also context. Of these mappings, characters with Unconditional Mappings or with Language-Insensitive Mappings in Conditional Mappings target are mapped into same codepoint(s) with just casefolding or special casefolding then casefolding. But characters with Language-Sensitive Mappings in Conditional Mappings targets are mapped into different codepoints. Therefore this document defines characters that are a part of characters of Lithuanian(lt), Turkish(tr) and Azerbaijanian(az) that Language-Sensitive Mappings targets as targets for local case mapping. As I read that text, it says: 1. "Local case mapping" applies only to the Language-Sensitive Mappings (one division of the Conditional Mappings) from SpecialCasing.txt 2. "Local case mapping" does not apply to the Language-Insensitive Mappings from SpecialCasing.txt (e.g., handling of Greek Final Sigma, which is context-dependent instead of language-dependent but still one of the Conditional Mappings) 3. "Local case mapping" also does not apply to the Unconditional Mappings from SpecialCasing.txt (which in general are mappings from lowercase to titlecase and uppercase anyway, so we might not care about them) If we look at the results in Appendix B.1 of draft-ietf-precis-mappings we see that they match the Language-Sensitive Mappings from the SpecialCasing.txt file. So if that's all we're doing here, I wonder why Section 2.3 of our document needs to be so long -- why not just say "apply the Language-Sensitive Mappings in SpecialCasing.txt" and be done with it? Or, do we also need to also specify some of the context-dependent mappings? (The major one is Greek final sigma.) As an example, in the PRECIS nickname spec would uppercase "ΦΙΛΟΣ ΜΟΙ" ("my friend") be case folded for comparison purposes to "φιλος μοι" (with a Greek final sigma, which is correct in Greek) or to "φιλοσ μοι" (with a Greek medial sigma, which is incorrect in Greek)? And what about full case folding vs. simple case folding (e.g., ẞ = U+1E9E to ss instead of ß = U+00DF)? Do we need to specify one way to handle characters where either full case folding or simple case folding can be applied, so that we have consistency for interop purposes? Perhaps I'm missing something obvious, but IMHO at least Section 2.3 needs to explain a bit more what we're trying to accomplish, and why. Peter -- Peter Saint-Andre https://stpeter.im/ From prvs=95347aba4=addison@lab126.com Thu Sep 5 07:16:39 2013 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 6752511E81A6 for ; Thu, 5 Sep 2013 07:16:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OXRp5IRC5f2N for ; Thu, 5 Sep 2013 07:16:28 -0700 (PDT) Received: from smtp-fw-2101.amazon.com (smtp-fw-2101.amazon.com [72.21.196.25]) by ietfa.amsl.com (Postfix) with ESMTP id E4BD411E81A7 for ; Thu, 5 Sep 2013 07:16:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.90,847,1371081600"; d="scan'208";a="596180126" Received: from smtp-in-5102.iad5.amazon.com ([10.218.9.29]) by smtp-border-fw-out-2101.iad2.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Sep 2013 14:16:25 +0000 Received: from ex10-hub-31005.ant.amazon.com (ex10-hub-31005.sea31.amazon.com [10.185.176.12]) by smtp-in-5102.iad5.amazon.com (8.13.8/8.13.8) with ESMTP id r85EGJXT020602 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 5 Sep 2013 14:16:24 GMT Received: from EX10-MBX-31004.ant.amazon.com ([fe80::5149:ac05:8b74:a95b]) by ex10-hub-31005.ant.amazon.com ([::1]) with mapi id 14.02.0342.003; Thu, 5 Sep 2013 07:16:23 -0700 From: "Phillips, Addison" To: Yoshiro YONEYA Thread-Topic: [precis] PRECIS and CharMod [I18N-ACTION-250] Thread-Index: Ac6qQe2NKFLGwrIURkmaJCsVPnTPNQ== Date: Thu, 5 Sep 2013 14:16:22 +0000 Message-ID: <7C0AF84C6D560544A17DDDEB68A9DFB50FF4012A@ex10-mbx-31004.ant.amazon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.184.49.66] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Precedence: Bulk Cc: "precis@ietf.org" , "member-i18n-core@w3.org" Subject: Re: [precis] PRECIS and CharMod [I18N-ACTION-250] X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 14:16:43 -0000 SGVsbG8gWW9zaGlybyBhbmQgUFJFQ0lTIFdHLA0KDQpJJ20gd3JpdGluZyBvbiBiZWhhbGYgb2Yg dGhlIEkxOE4gV0cgd2l0aCBhIHJlcXVlc3QuIE91ciBXRyBwcm9jZXNzIG5vcm1hbGx5IGluY2x1 ZGVzIGdyb3VwIHJldmlldyBvZiBjb21tZW50cyBiZWZvcmUgd2Ugc3VibWl0IHRoZW0uIE91ciB0 ZWxlY29uZmVyZW5jZXMgYXJlIG9uIFRodXJzZGF5cyBhbmQgeW91ciB1cGNvbWluZyBXR0xDIGlz IHNjaGVkdWxlZCB0byBlbmQgbmV4dCBXZWRuZXNkYXkuIFNvIEkndmUgYmVlbiB0YXNrZWQgd2l0 aCBsZXR0aW5nIHlvdSBrbm93IHRoYXQgd2UgaW50ZW5kIHRvIHN1Ym1pdCBjb21tZW50cywgYnV0 IHRoYXQgdGhleSB3aWxsIGJlIGEgbGl0dGxlIGxhdGUuIFdvdWxkIHlvdSBjb25zaWRlciBmb3Jt YWxseSBleHRlbmRpbmcgeW91ciBkZWFkbGluZSBieSBhIGRheT8NCg0KVGhhbmtzLA0KDQpBZGRp c29uDQoNCkFkZGlzb24gUGhpbGxpcHMNCkdsb2JhbGl6YXRpb24gQXJjaGl0ZWN0IChBbWF6b24g TGFiMTI2KQ0KQ2hhaXIgKFczQyBJMThOIFdHKQ0KDQpJbnRlcm5hdGlvbmFsaXphdGlvbiBpcyBu b3QgYSBmZWF0dXJlLg0KSXQgaXMgYW4gYXJjaGl0ZWN0dXJlLg0KDQoNCj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogWW9zaGlybyBZT05FWUEgW21haWx0bzp5b3NoaXJvLnlv bmV5YUBqcHJzLmNvLmpwXQ0KPiBTZW50OiBXZWRuZXNkYXksIEF1Z3VzdCAyOCwgMjAxMyA3OjA5 IFBNDQo+IFRvOiBQaGlsbGlwcywgQWRkaXNvbg0KPiBDYzogcHJlY2lzQGlldGYub3JnOyBtZW1i ZXItaTE4bi1jb3JlQHczLm9yZw0KPiBTdWJqZWN0OiBSZTogW3ByZWNpc10gUFJFQ0lTIGFuZCBD aGFyTW9kIFtJMThOLUFDVElPTi0yNDRdDQo+IA0KPiBEZWFyIEFkZGlzb24sDQo+IA0KPiBUaGFu ayB5b3UgZm9yIHJhaXNpbmcgdGhpcy4gIFZlcnkgdGltZWx5LCBwcmVjaXMnIGNvcmUgc3BlY2lm aWNhdGlvbiwgZnJhbWV3b3JrDQo+IChkcmFmdC1pZXRmLXByZWNpcy1mcmFtZXdvcmspIGJlZ3Vu IDIgd2Vla3MgV0cgTEMgeWVzdGVyZGF5LCBpbiBjb25qdW5jdGlvbg0KPiB3aXRoIGl0cyByZWxh dGVkIGRvY3VtZW50IChkcmFmdC1pZXRmLXByZWNpcy1tYXBwaW5ncykuDQo+IDxodHRwOi8vd3d3 LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvcHJlY2lzL2N1cnJlbnQvbXNnMDA1MDMuaHRtbD4N Cj4gPGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9wcmVjaXMvY3VycmVudC9t c2cwMDUwNC5odG1sPg0KPiANCj4gV291bGQgeW91IHBsZWFzZSByZXZpZXcgdGhlc2UgZG9jdW1l bnRzIGFuZCBnaXZlIHVzIGNvbW1lbnRzIGR1cmluZyB0aGUNCj4gV0cgTEMgdGVybT8gIEVzcGVj aWFsbHkgdGhvdWdodHMgYWJvdXQgYXBwbGljYWJpbGl0eSBvZiB0aGUgUFJFQ0lTIGZyYW1ld29y aw0KPiB0byBpZGVudGlmaWVycyBpbiBDaGFyTW9kIG5vcm1hbGl6YXRpb24gYXJlIHZlcnkgd2Vs Y29tZS4NCj4gDQo+IFJlZ2FyZHMsDQo+IA0KPiAtLQ0KPiBZb3NoaXJvIFlPTkVZQSA8eW9zaGly by55b25leWFAanBycy5jby5qcD4NCj4gDQo+IE9uIFdlZCwgMjggQXVnIDIwMTMgMTg6NDA6MDkg KzAwMDAgIlBoaWxsaXBzLCBBZGRpc29uIg0KPiA8YWRkaXNvbkBsYWIxMjYuY29tPiB3cm90ZToN Cj4gDQo+ID4gSGVsbG8gUHJlY2lzIHdvcmtpbmcgZ3JvdXAsDQo+ID4NCj4gPiBJJ20gd3JpdGlu ZyBvbiBiZWhhbGYgb2YgdGhlIFczQyBJbnRlcm5hdGlvbmFsaXphdGlvbiBXRyBbMV0uIFdlJ3Zl IG5vdGljZWQNCj4gdGhhdCB0aGUgd29yayB5b3UncmUgZG9pbmcgaW4geW91ciB2YXJpb3VzIGlu dGVybmV0LWRyYWZ0cyBpcyBjbG9zZWx5IHJlbGF0ZWQgdG8NCj4gd29yayB3ZSBhcmUgKGFuZCBo YXZlIGhpc3RvcmljYWxseSBiZWVuKSBkb2luZyBpbiB0aGUgQ2hhcmFjdGVyIE1vZGVsLiBJbg0K PiBwYXJ0aWN1bGFyLCB3ZSBhcmUgd29ya2luZyBvbiBhbiB1cGRhdGUgdG8gb3VyIE5vcm1hbGl6 YXRpb24gYW5kIHN0cmluZw0KPiBtYXRjaGluZyBkb2N1bWVudCBbMl1bM10uDQo+ID4NCj4gPiBX ZSB0aGluayBpdCB3b3VsZCBtYWtlIHNlbnNlIGlmIHRoZSBQUkVDSVMgYW5kIENoYXJNb2QgcmVj b21tZW5kYXRpb25zDQo+IHdlcmUgY29uc2lzdGVudCBpbiB3aGF0IHRoZXkgcmVxdWlyZS9yZWNv bW1lbmQuIEhvdyBjYW4gd2UgYmVzdA0KPiBjb29yZGluYXRlPw0KPiA+DQo+ID4gUmVnYXJkcyAo Zm9yIFczQyBJMThOKSwNCj4gPg0KPiA+IEFkZGlzb24NCj4gPg0KPiA+IFsxXSBodHRwOi8vd3d3 LnczLm9yZy9JbnRlcm5hdGlvbmFsLw0KPiA+IGh0dHA6Ly93d3cudzMub3JnL0ludGVybmF0aW9u YWwvdHJhY2svYWN0aW9ucy8yNDQNCj4gPiBbMl0gTmV3IERyYWZ0OiBodHRwOi8vd3d3LnczLm9y Zy9JbnRlcm5hdGlvbmFsL2RvY3MvY2hhcm1vZC1ub3JtLw0KPiA+IFszXSBIaXN0b3JpY2FsOiBo dHRwOi8vd3d3LnczLm9yZy9UUi8yMDEyL1dELWNoYXJtb2Qtbm9ybS0yMDEyMDUwMS8NCj4gPiBb NF0gaHR0cDovL3d3dy53My5vcmcvVFIvY2hhcm1vZC8NCj4gPg0KPiA+DQo+ID4gQWRkaXNvbiBQ aGlsbGlwcw0KPiA+IEdsb2JhbGl6YXRpb24gQXJjaGl0ZWN0IChBbWF6b24gTGFiMTI2KSBDaGFp ciAoVzNDIEkxOE4gV0cpDQo+ID4NCj4gPiBJbnRlcm5hdGlvbmFsaXphdGlvbiBpcyBub3QgYSBm ZWF0dXJlLg0KPiA+IEl0IGlzIGFuIGFyY2hpdGVjdHVyZS4NCj4gPg0KPiA+DQo+ID4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBwcmVjaXMgbWFp bGluZyBsaXN0DQo+ID4gcHJlY2lzQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9wcmVjaXMNCj4gPg0KPiA+DQoNCg== From stpeter@stpeter.im Thu Sep 5 09:23:51 2013 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 849C621F9E6A for ; Thu, 5 Sep 2013 09:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.465 X-Spam-Level: X-Spam-Status: No, score=-102.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IfneGLBvq0L4 for ; Thu, 5 Sep 2013 09:23:40 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 4620221F9D35 for ; Thu, 5 Sep 2013 09:23:40 -0700 (PDT) Received: from sjc-vpn2-1408.cisco.com (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 86E2B415E6; Thu, 5 Sep 2013 10:27:47 -0600 (MDT) Message-ID: <5228B008.3030203@stpeter.im> Date: Thu, 05 Sep 2013 10:23:36 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Phillips, Addison" References: <7C0AF84C6D560544A17DDDEB68A9DFB50FF4012A@ex10-mbx-31004.ant.amazon.com> In-Reply-To: <7C0AF84C6D560544A17DDDEB68A9DFB50FF4012A@ex10-mbx-31004.ant.amazon.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "precis@ietf.org" , "member-i18n-core@w3.org" Subject: Re: [precis] PRECIS and CharMod [I18N-ACTION-250] X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 16:23:52 -0000 On 9/5/13 8:16 AM, Phillips, Addison wrote: > Hello Yoshiro and PRECIS WG, > > I'm writing on behalf of the I18N WG with a request. Our WG process > normally includes group review of comments before we submit them. Our > teleconferences are on Thursdays and your upcoming WGLC is scheduled > to end next Wednesday. So I've been tasked with letting you know that > we intend to submit comments, but that they will be a little late. > Would you consider formally extending your deadline by a day? Hi Addison, I'll let Yoshiro and Marc comment on your request since they are the chairs. However, what is the best way for participants in the PRECIS WG to common on the Character Model document? Thanks! Peter -- Peter Saint-Andre https://stpeter.im/ From yoshiro.yoneya@jprs.co.jp Thu Sep 5 19:29:29 2013 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 D3EB811E8218 for ; Thu, 5 Sep 2013 19:29:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.444 X-Spam-Level: X-Spam-Status: No, score=-102.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gfflT+OraxYD for ; Thu, 5 Sep 2013 19:29:29 -0700 (PDT) Received: from off-send01.tyo.jprs.co.jp (off-send01.tyo.jprs.co.jp [IPv6:2001:df0:8:17::10]) by ietfa.amsl.com (Postfix) with ESMTP id 4D3E111E81F9 for ; Thu, 5 Sep 2013 19:29:22 -0700 (PDT) Received: from off-sendsmg01.tyo.jprs.co.jp (off-sendsmg01.tyo.jprs.co.jp [172.18.8.32]) by off-send01.tyo.jprs.co.jp (8.13.8/8.13.8) with ESMTP id r862TKsE032666; Fri, 6 Sep 2013 11:29:20 +0900 X-AuditID: ac120820-b7f196d00000167f-fb-52293dffc50f Received: from NOTE550 (off-cpu04.tyo.jprs.co.jp [172.18.4.14]) by off-sendsmg01.tyo.jprs.co.jp (Symantec Messaging Gateway) with SMTP id 6A.C1.05759.FFD39225; Fri, 6 Sep 2013 11:29:19 +0900 (JST) Date: Fri, 6 Sep 2013 11:29:16 +0900 From: Yoshiro YONEYA To: "Phillips, Addison" Message-Id: <20130906112916.ef177b6e08eca424a3171e8d@jprs.co.jp> In-Reply-To: <7C0AF84C6D560544A17DDDEB68A9DFB50FF4012A@ex10-mbx-31004.ant.amazon.com> References: <7C0AF84C6D560544A17DDDEB68A9DFB50FF4012A@ex10-mbx-31004.ant.amazon.com> X-Mailer: Sylpheed 3.3.0 (GTK+ 2.10.14; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrNIsWRmVeSWpSXmKPExsWyRoiFT/e/rWaQwa9fphYXlzhaXHp6mMVi 1/c/rA7MHkuW/GTyWLXB1+PovP2sAcxRXDYpqTmZZalF+nYJXBlv5z9kLlgnXbF97hKWBsYf ol2MnBwSAiYSM47uY4OwxSQu3FsPZHNxCAkcZ5R4u/YGI0iCRUBFYvn2iawgNpuAgcSvZb+Z QGwRAR2J5p8nWUBsZoE4idkNx8BqhAWsJNZPWwA0iIODV8BB4sfuBJAwp0CoxPe/O5lBbCGB EIkJF26wQuy1kLjQ1MEOUS4o8XeHMMRELYmHv25BTZeX2P52DvMERv5ZCFWzkFTNQlK1gJF5 FaNMflqabnFqXkpxbrqBoV5JZb5eVkFRsV4yiN7ECA5LDoUdjDNOGRxiFOBgVOLhLZiqESTE mlhWXJl7iFGSg0lJlDfQRjNIiC8pP6UyI7E4I76oNCe1+BCjBAezkgivuAZQjjclsbIqtSgf JiXNwaIkznv8z5lAIYH0xJLU7NTUgtQimKwMB4eSBO9ikKGCRanpqRVpmTklCGkmDk6Q4TxA w3tAaniLCxJzizPTIfKnGCWlxHm3gCQEQBIZpXlwva8YxYFeEObNB8nyAFMMXNcroIFMQAPT PquCDCxJREhJNTAaL3iSsUS6Ln/F3TttjHl33hxWjp140mvxqfPfi/TFD0x1VFtz9c7eVcmZ 3Y96c94wlE7cKOz/ZA5P+SnLrSn2Ze5hSTe5V+r/P+Nw+2ezsevd2viDl+9+OmdUETpL6/qz 7J9nfMSys7LDNPbV315izC1bHSl96DtL3LZnXy/+flm0OStG+cp/JZbijERDLeai4kQAQgqT Ru4CAAA= Cc: "precis@ietf.org" , "member-i18n-core@w3.org" Subject: Re: [precis] PRECIS and CharMod [I18N-ACTION-250] X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 02:29:29 -0000 Dear Addison, The most important thing of the WG LC is to gather useful comments from the WG members and related parties. Now we (the WG) know that we will get your comments on next Thursday, so we will accept it as comments submitted during the WG LC. We are looking forward to it. Regards, -- Yoshiro YONEYA On Thu, 5 Sep 2013 14:16:22 +0000 "Phillips, Addison" wrote: > Hello Yoshiro and PRECIS WG, > > I'm writing on behalf of the I18N WG with a request. Our WG process normally includes group review of comments before we submit them. Our teleconferences are on Thursdays and your upcoming WGLC is scheduled to end next Wednesday. So I've been tasked with letting you know that we intend to submit comments, but that they will be a little late. Would you consider formally extending your deadline by a day? > > Thanks, > > Addison > > Addison Phillips > Globalization Architect (Amazon Lab126) > Chair (W3C I18N WG) > > Internationalization is not a feature. > It is an architecture. > > > > -----Original Message----- > > From: Yoshiro YONEYA [mailto:yoshiro.yoneya@jprs.co.jp] > > Sent: Wednesday, August 28, 2013 7:09 PM > > To: Phillips, Addison > > Cc: precis@ietf.org; member-i18n-core@w3.org > > Subject: Re: [precis] PRECIS and CharMod [I18N-ACTION-244] > > > > Dear Addison, > > > > Thank you for raising this. Very timely, precis' core specification, framework > > (draft-ietf-precis-framework) begun 2 weeks WG LC yesterday, in conjunction > > with its related document (draft-ietf-precis-mappings). > > > > > > > > Would you please review these documents and give us comments during the > > WG LC term? Especially thoughts about applicability of the PRECIS framework > > to identifiers in CharMod normalization are very welcome. > > > > Regards, > > > > -- > > Yoshiro YONEYA > > > > On Wed, 28 Aug 2013 18:40:09 +0000 "Phillips, Addison" > > wrote: > > > > > Hello Precis working group, > > > > > > I'm writing on behalf of the W3C Internationalization WG [1]. We've noticed > > that the work you're doing in your various internet-drafts is closely related to > > work we are (and have historically been) doing in the Character Model. In > > particular, we are working on an update to our Normalization and string > > matching document [2][3]. > > > > > > We think it would make sense if the PRECIS and CharMod recommendations > > were consistent in what they require/recommend. How can we best > > coordinate? > > > > > > Regards (for W3C I18N), > > > > > > Addison > > > > > > [1] http://www.w3.org/International/ > > > http://www.w3.org/International/track/actions/244 > > > [2] New Draft: http://www.w3.org/International/docs/charmod-norm/ > > > [3] Historical: http://www.w3.org/TR/2012/WD-charmod-norm-20120501/ > > > [4] http://www.w3.org/TR/charmod/ > > > > > > > > > Addison Phillips > > > Globalization Architect (Amazon Lab126) Chair (W3C I18N WG) > > > > > > Internationalization is not a feature. > > > It is an architecture. > > > > > > > > > _______________________________________________ > > > precis mailing list > > > precis@ietf.org > > > https://www.ietf.org/mailman/listinfo/precis > > > > > > > > > From prvs=954797940=addison@lab126.com Thu Sep 5 20:29:53 2013 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 89AC011E823D for ; Thu, 5 Sep 2013 20:29:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vpV35PLQKMoA for ; Thu, 5 Sep 2013 20:29:49 -0700 (PDT) Received: from smtp-fw-33001.amazon.com (smtp-fw-33001.amazon.com [207.171.189.228]) by ietfa.amsl.com (Postfix) with ESMTP id A110811E823A for ; Thu, 5 Sep 2013 20:29:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.90,850,1371081600"; d="scan'208";a="613015170" Received: from smtp-in-31001.sea31.amazon.com ([10.184.168.27]) by smtp-border-fw-out-33001.sea14.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Sep 2013 03:29:46 +0000 Received: from ex10-hub-31006.ant.amazon.com (ex10-hub-31006.sea31.amazon.com [10.185.176.13]) by smtp-in-31001.sea31.amazon.com (8.13.8/8.13.8) with ESMTP id r863TiVZ012280 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 6 Sep 2013 03:29:45 GMT Received: from EX10-MBX-31004.ant.amazon.com ([fe80::5149:ac05:8b74:a95b]) by ex10-hub-31006.ant.amazon.com ([::1]) with mapi id 14.02.0342.003; Thu, 5 Sep 2013 20:29:44 -0700 From: "Phillips, Addison" To: Peter Saint-Andre Thread-Topic: [precis] PRECIS and CharMod [I18N-ACTION-250] Thread-Index: Ac6qQe2NKFLGwrIURkmaJCsVPnTPNQATQRMAAAxikuA= Date: Fri, 6 Sep 2013 03:29:43 +0000 Message-ID: <7C0AF84C6D560544A17DDDEB68A9DFB50FF42D47@ex10-mbx-31004.ant.amazon.com> References: <7C0AF84C6D560544A17DDDEB68A9DFB50FF4012A@ex10-mbx-31004.ant.amazon.com> <5228B008.3030203@stpeter.im> In-Reply-To: <5228B008.3030203@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.184.49.66] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "precis@ietf.org" , "member-i18n-core@w3.org" Subject: Re: [precis] PRECIS and CharMod [I18N-ACTION-250] X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 03:29:53 -0000 SGkgUGV0ZXIsDQoNClRoYW5rcyBmb3IgdGhlIG5vdGUuDQoNCklmIGluZGl2aWR1YWwgcGFydGlj aXBhbnRzIHdpc2ggdG8gY29tbWVudCwgdGhlIGluc3RydWN0aW9ucyBpbiB0aGUgU09URCBzZWN0 aW9uIGFwcGx5Og0KDQotLQ0KSWYgeW91IHdpc2ggdG8gbWFrZSBjb21tZW50cyByZWdhcmRpbmcg dGhpcyBkb2N1bWVudCwgcGxlYXNlIHNlbmQgdGhlbSB0byB3d3ctaW50ZXJuYXRpb25hbEB3My5v cmcgKHN1YnNjcmliZSwgYXJjaGl2ZXMpLiBBbGwgZmVlZGJhY2sgaXMgd2VsY29tZS4NCi0tDQoN CldlIG1haW50YWluIGlzc3VlcyBpbiBvdXIgdHJhY2tlciAoY3VycmVudGx5IHRoZXJlIGFyZSBu b25lIGZvciB0aGlzIGRvY3VtZW50KToNCg0KaHR0cHM6Ly93d3cudzMub3JnL0ludGVybmF0aW9u YWwvdHJhY2svcHJvZHVjdHMvNDkNCg0KSW5zdHJ1Y3Rpb25zIG9uIHVzaW5nIHRoZSB0cmFja2Vy IGFyZSBoZXJlOg0KDQpodHRwOi8vd3d3LnczLm9yZy9JbnRlcm5hdGlvbmFsL3Jldmlld3MvcmV2 aWV3LWluc3RydWN0aW9ucw0KDQp0aGFua3MsDQoNCkFkZGlzb24NCg0KQWRkaXNvbiBQaGlsbGlw cw0KR2xvYmFsaXphdGlvbiBBcmNoaXRlY3QgKEFtYXpvbikNCkNoYWlyIChXM0MgSTE4TiBXRykN Cg0KSW50ZXJuYXRpb25hbGl6YXRpb24gaXMgbm90IGEgZmVhdHVyZS4NCkl0IGlzIGFuIGFyY2hp dGVjdHVyZS4NCg0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogUGV0 ZXIgU2FpbnQtQW5kcmUgW21haWx0bzpzdHBldGVyQHN0cGV0ZXIuaW1dDQo+IFNlbnQ6IFRodXJz ZGF5LCBTZXB0ZW1iZXIgMDUsIDIwMTMgOToyNCBBTQ0KPiBUbzogUGhpbGxpcHMsIEFkZGlzb24N Cj4gQ2M6IFlvc2hpcm8gWU9ORVlBOyBwcmVjaXNAaWV0Zi5vcmc7IG1lbWJlci1pMThuLWNvcmVA dzMub3JnDQo+IFN1YmplY3Q6IFJlOiBbcHJlY2lzXSBQUkVDSVMgYW5kIENoYXJNb2QgW0kxOE4t QUNUSU9OLTI1MF0NCj4gDQo+IE9uIDkvNS8xMyA4OjE2IEFNLCBQaGlsbGlwcywgQWRkaXNvbiB3 cm90ZToNCj4gPiBIZWxsbyBZb3NoaXJvIGFuZCBQUkVDSVMgV0csDQo+ID4NCj4gPiBJJ20gd3Jp dGluZyBvbiBiZWhhbGYgb2YgdGhlIEkxOE4gV0cgd2l0aCBhIHJlcXVlc3QuIE91ciBXRyBwcm9j ZXNzDQo+ID4gbm9ybWFsbHkgaW5jbHVkZXMgZ3JvdXAgcmV2aWV3IG9mIGNvbW1lbnRzIGJlZm9y ZSB3ZSBzdWJtaXQgdGhlbS4gT3VyDQo+ID4gdGVsZWNvbmZlcmVuY2VzIGFyZSBvbiBUaHVyc2Rh eXMgYW5kIHlvdXIgdXBjb21pbmcgV0dMQyBpcyBzY2hlZHVsZWQNCj4gPiB0byBlbmQgbmV4dCBX ZWRuZXNkYXkuIFNvIEkndmUgYmVlbiB0YXNrZWQgd2l0aCBsZXR0aW5nIHlvdSBrbm93IHRoYXQN Cj4gPiB3ZSBpbnRlbmQgdG8gc3VibWl0IGNvbW1lbnRzLCBidXQgdGhhdCB0aGV5IHdpbGwgYmUg YSBsaXR0bGUgbGF0ZS4NCj4gPiBXb3VsZCB5b3UgY29uc2lkZXIgZm9ybWFsbHkgZXh0ZW5kaW5n IHlvdXIgZGVhZGxpbmUgYnkgYSBkYXk/DQo+IA0KPiBIaSBBZGRpc29uLA0KPiANCj4gSSdsbCBs ZXQgWW9zaGlybyBhbmQgTWFyYyBjb21tZW50IG9uIHlvdXIgcmVxdWVzdCBzaW5jZSB0aGV5IGFy ZSB0aGUgY2hhaXJzLg0KPiANCj4gSG93ZXZlciwgd2hhdCBpcyB0aGUgYmVzdCB3YXkgZm9yIHBh cnRpY2lwYW50cyBpbiB0aGUgUFJFQ0lTIFdHIHRvIGNvbW1vbiBvbg0KPiB0aGUgQ2hhcmFjdGVy IE1vZGVsIGRvY3VtZW50Pw0KPiANCj4gVGhhbmtzIQ0KPiANCj4gUGV0ZXINCj4gDQo+IC0tDQo+ IFBldGVyIFNhaW50LUFuZHJlDQo+IGh0dHBzOi8vc3RwZXRlci5pbS8NCj4gDQoNCg== From stpeter@stpeter.im Thu Sep 5 20:47:12 2013 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 C4D8721F9BBD for ; Thu, 5 Sep 2013 20:47:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DstYtB5c0gsE for ; Thu, 5 Sep 2013 20:47:07 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 8AC5321F9BA2 for ; Thu, 5 Sep 2013 20:47:06 -0700 (PDT) Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D898D415B2; Thu, 5 Sep 2013 21:51:13 -0600 (MDT) Message-ID: <52295035.7070002@stpeter.im> Date: Thu, 05 Sep 2013 21:47:01 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Phillips, Addison" References: <7C0AF84C6D560544A17DDDEB68A9DFB50FF4012A@ex10-mbx-31004.ant.amazon.com> <5228B008.3030203@stpeter.im> <7C0AF84C6D560544A17DDDEB68A9DFB50FF42D47@ex10-mbx-31004.ant.amazon.com> In-Reply-To: <7C0AF84C6D560544A17DDDEB68A9DFB50FF42D47@ex10-mbx-31004.ant.amazon.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "precis@ietf.org" , "member-i18n-core@w3.org" Subject: Re: [precis] PRECIS and CharMod [I18N-ACTION-250] X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 03:47:13 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/5/13 9:29 PM, Phillips, Addison wrote: > Hi Peter, > > Thanks for the note. > > If individual participants wish to comment, the instructions in the > SOTD section apply: > > -- If you wish to make comments regarding this document, please > send them to www-international@w3.org (subscribe, archives). All > feedback is welcome. -- > > We maintain issues in our tracker (currently there are none for > this document): > > https://www.w3.org/International/track/products/49 > > Instructions on using the tracker are here: > > http://www.w3.org/International/reviews/review-instructions Excellent. I'll add that document to my review list. By what date would you prefer to receive comments? Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSKVA1AAoJEOoGpJErxa2pdg8P/2mxeAuSWc2PqPBZUInUZYFh SCx4UtY6rd5CwuHVFKKek4acxvD4K+ABxkxfqD6EkurHohZ/ZlQ7qA0v/u3crDf0 IP0emagOdDHOPl+jhqMam2RhTn743YHjsd/H4562DYHXI2j/2pkvWi7NguC+BY2q MZNo9j6kQ3YZqIFqdI+X/7NZvUE7vINn2kUku1qSVot9ekgx70Pb4fhl+77GP/8S b9bSVojaLozGpshjHAtm4TjMGydFuiLYKqDROUAKNNiV3HXDX4mySIW01ZvPQ1D3 oKLC4/U6OE8Yprul+TE1clEeWNUkgAHjOyvSCmNTr5xZ/TnHc6zgvGo4KbyNOqDJ c35/3Nvp6c5dkRXUvtTjiE6iE1yN6PaA8ix5qw4XdnMSkP+zPZjsEmRB2Ui6NwM1 QeB/gkH6k4Ssi2J0oiYb5j/m5alsbybFCYBbObT5+WtjOUmuDb4r1t2GFISa3L1y GrJ2EC5HvLXl11PgFLtCYT7MVpTeR8cuNIlzGeqt+HkCXKlyUFVPAWCs7WjJIyBZ at7fFtjAMoRNjlpLCwb7wsCuhiJpJ3e/IVujw62O90z+zFbYNAXXKfS4MQWuDlA6 ivN2bHQmOJIrzilgkD+EaYwShhGB+9nRAC7Lk5KTqs8EMcqTLy2z8iH0MsUGt34o JHGzu13esCZXbqV1n/wb =zFzt -----END PGP SIGNATURE----- From prvs=954797940=addison@lab126.com Thu Sep 5 21:05:57 2013 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 7A58D11E824C for ; Thu, 5 Sep 2013 21:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GQJYmLvTlGuX for ; Thu, 5 Sep 2013 21:05:53 -0700 (PDT) Received: from smtp-fw-2101.amazon.com (smtp-fw-2101.amazon.com [72.21.196.25]) by ietfa.amsl.com (Postfix) with ESMTP id 234A711E822A for ; Thu, 5 Sep 2013 21:05:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.90,851,1371081600"; d="scan'208";a="596298087" Received: from smtp-in-1101.vdc.amazon.com ([10.146.54.37]) by smtp-border-fw-out-2101.iad2.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Sep 2013 04:05:51 +0000 Received: from ex10-hub-9004.ant.amazon.com (ex10-hub-9004.ant.amazon.com [10.185.137.182]) by smtp-in-1101.vdc.amazon.com (8.13.8/8.13.8) with ESMTP id r8645lRj016889 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 6 Sep 2013 04:05:51 GMT Received: from EX10-MBX-31004.ant.amazon.com ([fe80::5149:ac05:8b74:a95b]) by ex10-hub-9004.ant.amazon.com ([::1]) with mapi id 14.02.0342.003; Thu, 5 Sep 2013 21:03:26 -0700 From: "Phillips, Addison" To: Peter Saint-Andre Thread-Topic: [precis] PRECIS and CharMod [I18N-ACTION-250] Thread-Index: Ac6qQe2NKFLGwrIURkmaJCsVPnTPNQATQRMAAAxikuAAC3umgAAOpbUw Date: Fri, 6 Sep 2013 04:03:26 +0000 Message-ID: <7C0AF84C6D560544A17DDDEB68A9DFB50FF42EDB@ex10-mbx-31004.ant.amazon.com> References: <7C0AF84C6D560544A17DDDEB68A9DFB50FF4012A@ex10-mbx-31004.ant.amazon.com> <5228B008.3030203@stpeter.im> <7C0AF84C6D560544A17DDDEB68A9DFB50FF42D47@ex10-mbx-31004.ant.amazon.com> <52295035.7070002@stpeter.im> In-Reply-To: <52295035.7070002@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.184.49.66] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Precedence: Bulk Cc: "precis@ietf.org" , "member-i18n-core@w3.org" Subject: Re: [precis] PRECIS and CharMod [I18N-ACTION-250] X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 04:05:57 -0000 VGhlIGN1cnJlbnQgdmVyc2lvbiBoYXMgYSBsYXJnZSBob2xlIGluIGl0IChTZWN0aW9uIDQpLCB3 aGljaCB3ZSBob3BlIHRvIGZpbGwgaW4gdHdvIGVkaXQgc2Vzc2lvbnMgcGxhbm5lZCBiZXR3ZWVu IG5vdyBhbmQgdGhlIGVuZCBvZiBPY3RvYmVyLiBGb2xsb3dpbmcgdGhhdCwgd2UgaW50ZW5kIHRv IHB1Ymxpc2ggYSBjb21wbGV0ZSB2ZXJzaW9uIGZvciBmb3JtYWwgcmV2aWV3LiBBbnkgcmV2aWV3 IGF0IHRoaXMgcG9pbnQgd291bGQgYmUgdmVyeSBoZWxwZnVsLg0KDQpJZiB5b3UgYXJlIGZhbWls aWFyIHdpdGggdGhlIG9sZCBjaGFybW9kIFsxXSwgeW91J2xsIGFwcHJlY2lhdGUgdGhhdCB3ZSd2 ZSB0b3JuIHRoZSBkb2N1bWVudCBkb3duIGFuZCByZXBsYWNlZCBtb3N0IG9mIGl0LiBUaGUgbWF0 Y2hpbmcgc2VjdGlvbnMgYXJlIGEgY2xvc2VyIGZpdCB0byB3aGF0IHByw6ljaXMgaXMgd29ya2lu ZyBvbiAoYW5kIHJlZmxlY3Qgd2hhdCB3ZSdyZSBjb25jZXJuZWQgYWJvdXQgYmVpbmcgY29uc2lz dGVudCB3aXRoKS4gVGhlIHNlYXJjaGluZyBzZWN0aW9uIGlzIGludGVuZGVkIHRvIGNvdmVyIHRo ZSBDdHJsLUYgZmVhdHVyZSBpbiBicm93c2VycyAoYW5kIHNpbWlsYXIgb3BlcmF0aW9ucyksIHJh dGhlciB0aGFuIGZvcm1hbCBsYW5ndWFnZXMgb3IgcHJvdG9jb2xzLg0KDQpBZGRpc29uDQoNClsx XSBodHRwOi8vd3d3LnczLm9yZy9UUi9jaGFybW9kLW5vcm0vDQoNCj4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4gRnJvbTogUGV0ZXIgU2FpbnQtQW5kcmUgW21haWx0bzpzdHBldGVyQHN0 cGV0ZXIuaW1dDQo+IFNlbnQ6IFRodXJzZGF5LCBTZXB0ZW1iZXIgMDUsIDIwMTMgODo0NyBQTQ0K PiBUbzogUGhpbGxpcHMsIEFkZGlzb24NCj4gQ2M6IFlvc2hpcm8gWU9ORVlBOyBwcmVjaXNAaWV0 Zi5vcmc7IG1lbWJlci1pMThuLWNvcmVAdzMub3JnDQo+IFN1YmplY3Q6IFJlOiBbcHJlY2lzXSBQ UkVDSVMgYW5kIENoYXJNb2QgW0kxOE4tQUNUSU9OLTI1MF0NCj4gDQo+IC0tLS0tQkVHSU4gUEdQ IFNJR05FRCBNRVNTQUdFLS0tLS0NCj4gSGFzaDogU0hBMQ0KPiANCj4gT24gOS81LzEzIDk6Mjkg UE0sIFBoaWxsaXBzLCBBZGRpc29uIHdyb3RlOg0KPiA+IEhpIFBldGVyLA0KPiA+DQo+ID4gVGhh bmtzIGZvciB0aGUgbm90ZS4NCj4gPg0KPiA+IElmIGluZGl2aWR1YWwgcGFydGljaXBhbnRzIHdp c2ggdG8gY29tbWVudCwgdGhlIGluc3RydWN0aW9ucyBpbiB0aGUNCj4gPiBTT1REIHNlY3Rpb24g YXBwbHk6DQo+ID4NCj4gPiAtLSBJZiB5b3Ugd2lzaCB0byBtYWtlIGNvbW1lbnRzIHJlZ2FyZGlu ZyB0aGlzIGRvY3VtZW50LCBwbGVhc2Ugc2VuZA0KPiA+IHRoZW0gdG8gd3d3LWludGVybmF0aW9u YWxAdzMub3JnIChzdWJzY3JpYmUsIGFyY2hpdmVzKS4gQWxsIGZlZWRiYWNrDQo+ID4gaXMgd2Vs Y29tZS4gLS0NCj4gPg0KPiA+IFdlIG1haW50YWluIGlzc3VlcyBpbiBvdXIgdHJhY2tlciAoY3Vy cmVudGx5IHRoZXJlIGFyZSBub25lIGZvciB0aGlzDQo+ID4gZG9jdW1lbnQpOg0KPiA+DQo+ID4g aHR0cHM6Ly93d3cudzMub3JnL0ludGVybmF0aW9uYWwvdHJhY2svcHJvZHVjdHMvNDkNCj4gPg0K PiA+IEluc3RydWN0aW9ucyBvbiB1c2luZyB0aGUgdHJhY2tlciBhcmUgaGVyZToNCj4gPg0KPiA+ IGh0dHA6Ly93d3cudzMub3JnL0ludGVybmF0aW9uYWwvcmV2aWV3cy9yZXZpZXctaW5zdHJ1Y3Rp b25zDQo+IA0KPiBFeGNlbGxlbnQuIEknbGwgYWRkIHRoYXQgZG9jdW1lbnQgdG8gbXkgcmV2aWV3 IGxpc3QuIEJ5IHdoYXQgZGF0ZSB3b3VsZCB5b3UNCj4gcHJlZmVyIHRvIHJlY2VpdmUgY29tbWVu dHM/DQo+IA0KPiBQZXRlcg0KPiANCj4gLSAtLQ0KPiBQZXRlciBTYWludC1BbmRyZQ0KPiBodHRw czovL3N0cGV0ZXIuaW0vDQo+IA0KPiANCj4gLS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0N Cj4gVmVyc2lvbjogR251UEcvTWFjR1BHMiB2Mi4wLjE5IChEYXJ3aW4pDQo+IENvbW1lbnQ6IEdQ R1Rvb2xzIC0gaHR0cDovL2dwZ3Rvb2xzLm9yZw0KPiBDb21tZW50OiBVc2luZyBHbnVQRyB3aXRo IFRodW5kZXJiaXJkIC0gaHR0cDovL3d3dy5lbmlnbWFpbC5uZXQvDQo+IA0KPiBpUUljQkFFQkFn QUdCUUpTS1ZBMUFBb0pFT29HcEpFcnhhMnBkZzhQLzJteGVBdVNXYzJQcVBCWlVJblVaWUYNCj4g aA0KPiBTQ3g0VXRZNnJkNUN3dUhWRktLZWs0YWN4dkQ0SytBQnhreGZxRDZFa3VySG9oWi9abFE3 cUEwdi91M2NyRGYwDQo+IElQMGVtYWdPZERIT1BsK2pocU1hbTJSaFRuNzQzWUhqc2QvSDQ1NjJE WUhYSTJqLzJwa3ZXaTdOZ3VDK0JZMg0KPiBxDQo+IE1aTm85ajZrUTNZWnFJRnFkSStYLzdOWnZV RTd2SU5uMmtVa3UxcVNWb3Q5ZWtneDcwUGI0ZmhsKzc3R1AvOFMNCj4gYjliU1ZvamFMb3pHcHNo akhBdG00VGpNR3lkRnVpTFlLcURST1VBS05OaVYzSFhEWDRteVNJVzAxWnZQUTFEDQo+IDMNCj4g b0tMQzQvVTZPRThZcHJ1bCtURTFjbEVlV05Va2dBSGpPeXZTQ21OVHI1eFovVG5IYzZ6Z3ZHbzRL YnlOT3FESg0KPiBjMzUvM052cDZjNWRrUlhVdnRUamlFNmlFMXlONlBhQThpeDVxdzRYZG5NU2tQ K3pQWmpzRW1SQjJVaTZOd00xDQo+IFFlQi9na0g2azRTc2kySjBvaVliNWovbTVhbHNieWJGQ1lC Yk9iVDUrV3RqT1VtdURiNHIxdDJHRklTYTNMMXkNCj4gR3JKMkVDNUh2TFhsMTFQZ0ZMdENZVDdN VnBUZVI4Y3VOSWx6R2VxdCtIa0NYS2x5VUZWUEFXQ3M3V2pKSXlCWg0KPiBhdDdmRnRqQU1vUk5q bHBMQ3diN3dzQ3VoaUpwSjNlL0lWdWp3NjJPOTB6K3pGYllOQVhYS2ZTNE1RV3VEbEE2DQo+IGl2 TjJiSFFtT0pJcnppbGdrRCtFYVl3U2hoR0IrOW5SQUM3TGs1S1RxczhFTWNxVEx5Mno4aUgwTXNV R3QzNG8NCj4gSkhHenUxM2VzQ1pYYnFWMW4vd2INCj4gPXpGenQNCj4gLS0tLS1FTkQgUEdQIFNJ R05BVFVSRS0tLS0tDQo= From alexey.melnikov@isode.com Sun Sep 8 09:54:07 2013 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 3644121F8E70 for ; Sun, 8 Sep 2013 09:54:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.27 X-Spam-Level: X-Spam-Status: No, score=-103.27 tagged_above=-999 required=5 tests=[AWL=-0.671, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rsYN39amZFYk for ; Sun, 8 Sep 2013 09:54:02 -0700 (PDT) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id 079B121F8D12 for ; Sun, 8 Sep 2013 09:54:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1378659241; d=isode.com; s=selector; i=@isode.com; bh=zfcHd3HlQEXKvhV8PcqAIrSytAmVUhPJgfgSmGq+pI4=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=DraRkO7vnDi3C2D2CN7FbEeZnAtPnXp3FzBCv75ZiqeUbAys4m/NJBc3Xfa+r4EDUz1hmn CRZvLZD6Lf9O/fwbWfELThsoBW+fGsNCZhFrYI5RuebFeJlaTJwsDVVn8iOIcmqbOU8kSD HqvgBKG5K3+CMcPQHl7SW2fS49XQXgE=; Received: from [192.168.0.4] (cpc5-nmal20-2-0-cust24.19-2.cable.virginmedia.com [92.234.84.25]) by statler.isode.com (submission channel) via TCP with ESMTPA id ; Sun, 8 Sep 2013 17:54:01 +0100 Message-ID: <522CABA7.6020107@isode.com> Date: Sun, 08 Sep 2013 17:53:59 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 To: precis@ietf.org References: <20130828154603.a94201dea74f29229b4767b2@jprs.co.jp> In-Reply-To: <20130828154603.a94201dea74f29229b4767b2@jprs.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [precis] WGLC: draft-ietf-precis-framework-09.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 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, 08 Sep 2013 16:54:07 -0000 On 28/08/2013 07:46, Yoshiro YONEYA wrote: > Dear all, > > This message starts two weeks Working Group Last Call (WGLC) on > draft-ietf-precis-framework-09.txt (PRECIS Framework: Preparation and > Comparison of Internationalized Strings in Application Protocols). > > Please review the document and send comments to the list (precis@ietf.org), > the co-chairs (precis-chairs@tools.ietf.org), or the authors > (draft-ietf-precis-framework@tools.ietf.org) by the end of WGLC. > > The WGLC will end on Wednesday, Sep 11th. I reviewed the document and generally found no issues with it. I have 1 nit: In Section 5: Please replace NAME with ID in a couple of places. (I think one of Precis classes was renamed, but this was not reflected everywhere in the document.) From stpeter@stpeter.im Mon Sep 9 16:42:27 2013 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 B58A811E80F3 for ; Mon, 9 Sep 2013 16:42:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wfku6DsYmcN4 for ; Mon, 9 Sep 2013 16:42:23 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 573F411E80FE for ; Mon, 9 Sep 2013 16:42:23 -0700 (PDT) Received: from sjc-vpn2-571.cisco.com (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 1FB8F415BA; Mon, 9 Sep 2013 17:46:45 -0600 (MDT) Message-ID: <522E5CDD.3020700@stpeter.im> Date: Mon, 09 Sep 2013 17:42:21 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "precis@ietf.org" References: <522E5CAA.5010902@stpeter.im> In-Reply-To: <522E5CAA.5010902@stpeter.im> X-Enigmail-Version: 1.5.2 X-Forwarded-Message-Id: <522E5CAA.5010902@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [precis] Fwd: Re: [kitten] Fwd: Re: I-D Action: draft-ietf-precis-saslprepbis-04.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 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, 09 Sep 2013 23:42:27 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 FYI, I finally remembered to ping the KITTEN WG about an issue that was raised in Berlin... Peter - -------- Original Message -------- Subject: Re: [kitten] Fwd: Re: [precis] I-D Action: draft-ietf-precis-saslprepbis-04.txt Date: Mon, 09 Sep 2013 17:41:30 -0600 From: Peter Saint-Andre To: kitten@ietf.org Dear KITTEN WG, Your feedback would be appreciated on this I-D. This version incorporates the input that Alexey and I received from folks here, as well as discussion at the PRECIS WG session in Berlin: http://www.ietf.org/proceedings/87/minutes/minutes-87-precis One question in particular regarding preparation of usernames, especially for Nico since he suggested the original text... Version -03 said: 3. Uppercase and titlecase characters MAY be mapped to their lowercase equivalents. In version -04, based on PRECIS WG discussion, we changed that to: 3. Uppercase and titlecase characters SHOULD be mapped to their lowercase equivalents (not doing so can lead to false positives during authentication and authorization, as described in [RFC6943]). The rationale was that we really don't want to give people a gun to shoot themselves with. Some folks in the PRECIS WG session leaned even to "MUST" here, but SHOULD with an explanation of the consequences was a compromise position. In any case, the original MAY seemed way too weak to folks in the PRECIS WG. Please let us know if you have grave concerns about the text in -04. Thanks! Peter On 8/12/13 10:38 AM, Peter Saint-Andre wrote: > FYI. > > > -------- Original Message -------- Subject: Re: [precis] I-D > Action: draft-ietf-precis-saslprepbis-04.txt Date: Sun, 04 Aug > 2013 18:06:49 -0600 From: Peter Saint-Andre > To: precis@ietf.org > > Changes to address discussion in the WG session on Friday. I did > this work in airports and on planes today, so I would not be > surprised if the text isn't perfect... > > On 8/4/13 6:04 PM, internet-drafts@ietf.org wrote: >> >> 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 Working >> Group of the IETF. >> >> Title : Preparation and Comparison of >> Internationalized Strings Representing Usernames and Passwords >> Author(s) : Peter Saint-Andre Alexey Melnikov Filename >> : draft-ietf-precis-saslprepbis-04.txt Pages : 14 Date >> : 2013-08-04 >> >> Abstract: This document describes how to handle Unicode strings >> representing usernames and passwords. This profile is intended >> to be used by protocols that exchange or otherwise make use of >> usernames and passwords. This document obsoletes RFC 4013. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-precis-saslprepbis >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-precis-saslprepbis-04 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-precis-saslprepbis-04 >> >> >> >> 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/ >> >> _______________________________________________ precis mailing >> list precis@ietf.org >> https://www.ietf.org/mailman/listinfo/precis >> -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSLlzdAAoJEOoGpJErxa2psbEP/RPS9Y/tPbD/pgp690b13ccr s7mvOzFm8eYGxGdMY/MR5zgxPjmHbzzDdKuyee6B8lMCOv9raA3jk3feBMJ8/YYd ctTHRuic6BiSvusZ9GPaLBI7KJMH3ZivZZQ0KMW0Vw76Y8vj4z2oo7mDTgauemGB 2JOT5wCGkwDGTA5vcpiY4Q7oc1OTn7q/CUQrTxLaer+v9+kz/ccdkz1almJxDIRO F+D/mVA9tCN03PEdYQhH6mFnxnvSxRHk7K/MXH6KfihKakUsEhBL/1Mrlm78du/v bldJ8gikgZIlNFfzm6PFMv4o5SCkGz7JmZMigsby9e4jXaJxYIxS7uAE2EInhbt9 nz+BT1r4lqodiArhNAIFV4fddbXfsNO1R/Y5reoiLFrCOJC3upqQAn9AB1YQiu+9 rxoDFJgFm4O3K16zyE2AoL/OmAC6lbSTbthd8VZ9NOGC8bDCJ/WNXU/443tt5E2w QXOdKxACQzCkhwKukG5P8djAnB/6Qghl/DVlENYuZ/ujXI0MQxfwL+JoEsw340BL trqleTdZhrEMV+Mqh9uaUS3O/dTSY3jLi/qkDE9KebSA9WZ9yCmP5pKbmdi0Zw4g Fxt60nbz8zX42XLaDUlfiJ3jfq7gLBMXBZvT7Wwa6vYXG+gFjj+yDjbqcyF211jq YsM5FMSaY+npICG6NVb7 =ogEy -----END PGP SIGNATURE----- From nico@cryptonector.com Tue Sep 10 07:06:36 2013 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 076EA21E8051; Tue, 10 Sep 2013 07:06:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.676 X-Spam-Level: X-Spam-Status: No, score=-1.676 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jDkXJbUajmlA; Tue, 10 Sep 2013 07:06:31 -0700 (PDT) Received: from homiemail-a88.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 9AD0521F9FB3; Tue, 10 Sep 2013 07:06:26 -0700 (PDT) Received: from homiemail-a88.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTP id D21AA264085; Tue, 10 Sep 2013 07:06:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=zLYq7gI5eip8EI+yPnoT Dkl4Z1A=; b=PdXkC8iDaTbsHE0b5+8Hs+jdSFbAQQWAlHcQ0Ymcb/2Ps6GkJ/6Q 7reqQIMxLdK0AgWQKLHmcWuhdMES4o2o5p1Qbj3/jZOR7va5SRxZF1FI67WXnDWB z0De+gCT2hGPYdKe/7jhE6GFbVsNsiCf96C2G7PwtcRvvTY0BOuCUn8= Received: from mail-we0-f179.google.com (mail-we0-f179.google.com [74.125.82.179]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTPSA id CBBE6264087; Tue, 10 Sep 2013 07:06:23 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id x55so5687517wes.10 for ; Tue, 10 Sep 2013 07:06:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=igeK5CRE2xg2wkVreP47WXTipvIRetPBa6OITIxfTTI=; b=aodPs3IgXmPWsIFxIVR7OUbmJM/raK/9Hk09i+EVJb4MMjoSKYhp93bBh4Nvavx5ez 87NalKZyHWSuLoehi3CFre8L/M2fa25pzF8+U/YCrATEeVRK35wsqRKFz76Hs0f/03dt rUvTu4LsKBc0qBteLNn9gEe9ojQXQNC7UlGCb1ge6RjjF5ZzLlGBbacwcq8hhf+dcRt4 56e6k9SSHMfUjUmq75ooOd+UUuHUhm2xtfjuGSq5hfNsifX/S87OfVHIx/cmldMlKvgd Br3ufRab/GWR6bJrtV/E6SAzTJ5QtAfeFGfKIKoHB1NLCI/kuJv+gqAxcFW0XZzw0VgE FrNg== MIME-Version: 1.0 X-Received: by 10.194.48.74 with SMTP id j10mr2651242wjn.41.1378821980992; Tue, 10 Sep 2013 07:06:20 -0700 (PDT) Received: by 10.216.31.193 with HTTP; Tue, 10 Sep 2013 07:06:20 -0700 (PDT) In-Reply-To: <522E5CAA.5010902@stpeter.im> References: <51FEEC99.1020901@stpeter.im> <52090F96.30700@stpeter.im> <522E5CAA.5010902@stpeter.im> Date: Tue, 10 Sep 2013 09:06:20 -0500 Message-ID: From: Nico Williams To: Peter Saint-Andre Content-Type: multipart/alternative; boundary=047d7ba975c862f67104e6080227 Cc: "kitten@ietf.org" , "precis@ietf.org" Subject: Re: [precis] [kitten] Fwd: Re: I-D Action: draft-ietf-precis-saslprepbis-04.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 14:06:36 -0000 --047d7ba975c862f67104e6080227 Content-Type: text/plain; charset=UTF-8 On Monday, September 9, 2013, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Dear KITTEN WG, > > Your feedback would be appreciated on this I-D. This version > incorporates the input that Alexey and I received from folks here, as > well as discussion at the PRECIS WG session in Berlin: > > http://www.ietf.org/proceedings/87/minutes/minutes-87-precis > > One question in particular regarding preparation of usernames, > especially for Nico since he suggested the original text... > > Version -03 said: > > 3. Uppercase and titlecase characters MAY be mapped to their > lowercase equivalents. > > In version -04, based on PRECIS WG discussion, we changed that to: > > 3. Uppercase and titlecase characters SHOULD be mapped to their > lowercase equivalents (not doing so can lead to false positives > during authentication and authorization, as described in > [RFC6943]). > > The rationale was that we really don't want to give people a gun to > shoot themselves with. Some folks in the PRECIS WG session leaned even > to "MUST" here, but SHOULD with an explanation of the consequences was > a compromise position. In any case, the original MAY seemed way too > weak to folks in the PRECIS WG. Please let us know if you have grave > concerns about the text in -04. > This is the third time, I think, that I've had to voice my vehement objections to this. I thought we were done the second time. I believe SASL applications and mechanisms MUST NOT do the above, not on the client side, and that the server should be allowed to do what it wishes. The only exception is for password (and salt) processing in DIGEST/SCRAM-like mechanisms where keys are derived from passwords on the client- (and server-) sides, therefore canonical password representations are desirable, and even then, case folding would be nothing short of -- and I must be utterly frank here-- stupid, as it means dropping entropy needlessly. The argument I made before was that we need to distinguish between query, display, and storage strings. If a username must be canonicalized then this should be done where it must be used as a databased/directory lookup key or as a cryptographic salt (where roughly the same considerations as for passwords used to derive keys apply). We should delay canonicalization as much as possible so as to support the server operator's choice of canonicalization. I've mentioned before that many online games allow all sorts of username forms that we'd consider silly in an enterprise environment, but in online gaming they are quite desirable as a form of styling. Let's not put a straightjacket on users of this string preparation -- let each operator pick their poison as much as possible. The RFC6943 reference should be more specific. What specific confusion cases are we worried about? Please have this argument on the KITTEN WG list. I'm cc'ing precis@ietf.orgjust this once, and I will not subscribe to it. We've had at least two debates on SASLprep-bis at KITTEN. Nico -- --047d7ba975c862f67104e6080227 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Monday, September 9, 2013, Peter Saint-Andre wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dear KITTEN WG,

Your feedback would be appreciated on this I-D. This version
incorporates the input that Alexey and I received from folks here, as
well as discussion at the PRECIS WG session in Berlin:

http://www.ietf.org/proceedings/87/minutes/minutes-87-preci= s

One question in particular regarding preparation of usernames,
especially for Nico since he suggested the original text...

Version -03 said:

=C2=A0 =C2=A03. =C2=A0Uppercase and titlecase characters MAY be mapped to t= heir
=C2=A0 =C2=A0 =C2=A0 =C2=A0lowercase equivalents.

In version -04, based on PRECIS WG discussion, we changed that to:

=C2=A0 =C2=A03. =C2=A0Uppercase and titlecase characters SHOULD be mapped t= o their
=C2=A0 =C2=A0 =C2=A0 =C2=A0lowercase equivalents (not doing so can lead to = false positives
=C2=A0 =C2=A0 =C2=A0 =C2=A0during authentication and authorization, as desc= ribed in
=C2=A0 =C2=A0 =C2=A0 =C2=A0[RFC6943]).

The rationale was that we really don't want to give people a gun to
shoot themselves with. Some folks in the PRECIS WG session leaned even
to "MUST" here, but SHOULD with an explanation of the consequence= s was
a compromise position. In any case, the original MAY seemed way too
weak to folks in the PRECIS WG. Please let us know if you have grave
concerns about the text in -04.

This is the third time, I think, that I= 9;ve had to voice my vehement objections to this. =C2=A0I thought we were d= one the second time. =C2=A0I believe SASL applications and mechanisms MUST = NOT do the above, not on the client side, and that the server should be all= owed to do what it wishes. =C2=A0The only exception is for password (and sa= lt)=C2=A0processing in DIGEST/SCRAM-like mechanisms where keys are derived = from passwords on the client- (and server-) sides,=C2=A0therefore=C2=A0cano= nical password representations are desirable, and even then, case folding w= ould be nothing short of -- and I must be utterly frank here-- stupid, as i= t means dropping entropy needlessly.

The argument I made before was that we need to distingu= ish between query, display, and storage strings. =C2=A0If a username must b= e canonicalized then this should be done where it must be used as a databas= ed/directory lookup key or as a cryptographic salt (where roughly the same = considerations as for passwords used to derive keys apply). =C2=A0We should= delay canonicalization as much as possible so as to support the server ope= rator's choice of canonicalization. =C2=A0I've mentioned before tha= t many online games allow all sorts of username forms that we'd conside= r silly in an enterprise environment, but in online gaming they are quite d= esirable as a form of styling. =C2=A0Let's not put a straightjacket on = users of this string preparation -- let each operator pick their poison as = much as possible.

The RFC6943 reference should be more specific. =C2=A0Wh= at specific confusion cases are we worried about?
Please have this argument on the KITTEN WG list. =C2=A0I'm= cc'ing precis@ietf.org just thi= s once, and I will not subscribe to it. =C2=A0We've had at least two de= bates on=C2=A0SASLprep-bis at KITTEN.

Nico
--=C2=A0 --047d7ba975c862f67104e6080227-- From florob@babelmonkeys.de Tue Sep 10 19:07:14 2013 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 5C52F21E805D for ; Tue, 10 Sep 2013 19:07:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qpA9bP4wdvmP for ; Tue, 10 Sep 2013 19:07:13 -0700 (PDT) Received: from babelmonkeys.de (babelmonkeys.de [IPv6:2a02:d40:3:1:10a1:5eff:fe52:509]) by ietfa.amsl.com (Postfix) with ESMTP id 67CE621E804E for ; Tue, 10 Sep 2013 19:07:12 -0700 (PDT) Received: from xdsl-78-34-218-232.netcologne.de ([78.34.218.232] helo=[192.168.234.39]) by babelmonkeys.de with esmtpsa (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1VJZqs-0005da-Q7 for precis@ietf.org; Wed, 11 Sep 2013 04:08:20 +0200 Message-ID: <522FD033.3070001@babelmonkeys.de> Date: Wed, 11 Sep 2013 04:06:43 +0200 From: Florian Zeitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130806 Thunderbird/17.0.8 MIME-Version: 1.0 To: precis@ietf.org References: <20130828154603.a94201dea74f29229b4767b2@jprs.co.jp> In-Reply-To: <20130828154603.a94201dea74f29229b4767b2@jprs.co.jp> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [precis] WGLC: draft-ietf-precis-framework-09.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2013 02:07:14 -0000 Am 28.08.2013 08:46, schrieb Yoshiro YONEYA: > Dear all, > > This message starts two weeks Working Group Last Call (WGLC) on > draft-ietf-precis-framework-09.txt (PRECIS Framework: Preparation and > Comparison of Internationalized Strings in Application Protocols). > > Please review the document and send comments to the list (precis@ietf.org), > the co-chairs (precis-chairs@tools.ietf.org), or the authors > (draft-ietf-precis-framework@tools.ietf.org) by the end of WGLC. > > The WGLC will end on Wednesday, Sep 11th. > I've reviewed this draft, and generally think it takes a sensible approach. However, I do have one major grief about it, as well as some smaller comments. The major thing that bothers me about this draft is that string classes IMHO conflate to separate concepts. On the one hand they specify valid and disallowed codepoints. On the other hand they specify (or rather, let the application protocol specify) mappings and normalization. The problem I have with this is, that it makes it unclear which strings are valid in a certain class. E.g. consider an applications protocol that specifies FreeformClass mixed with NFKC. This means characters, which have a compatibility equivalent are valid in the sense that they are FREE_PVAL, but are invalid in the normalization form. It is unclear to me, whether a string containing characters with a compatibility equivalent would be contained in the FreeformClass, or more precisely, this specialization thereof. Similar considerations are true for e.g. mixing case mapping with IdentifierClass. Uppercase characters are PVALID/ID_PVAL, but shouldn't be present after mapping. I would prefer it if we specified classes solely in terms of valid and disallowed codepoints and directionality requirements. We would then have separate text saying that an application protocol MUST also specify which mappings and normalization to apply, what entity needs to apply them (e.g. only the server), and when they need to be applied (e.g. when comparing strings, before storing them, before display to a user). Both StringPrep-bis and 6122bis already have text to this effect. It seems sensible to me to generally require application protocols to specify the "who", and "when" beyond the "what". E.g. it is often sensible to display identifiers with their case as entered, but compare them after case folding. The current text might suggest that mappings have to be applied to user input immediately. The following are smaller comments ordered by section: Section 3.1: This section talks about "safety" of strings, without ever defining what that means in this context. The term "very safe" used to describe the IdentifierClass also strangely reminds me of statements about "absolute security". Maybe there is a way to generally word this better? The sentence "Directionality: defines application behavior in the presence of code points that have directionality" seems a bit off to me. It is very different from the explanation given later in Section 4.1. >From my understanding this is about the allowed combinations of characters with directionality, and not about "application beahvior" in their presence. It could be about both, but I have not seen a draft talk about anything but allowed combinations (i.e. the Bidi Rule) yet. Section 3.3.3 and 3.4.3: While "unassigned codepoints are unassigned" is a nice tautology, I'm not sure what this means in terms of their treatment. In general I feel like more explanation is needed about unassigned codepoints and their (possible) handling. Section 3.3.6: I think it would be sensible to suggest using the Unicode Default Case Folding algorithm, if case mapping is to be applied. Section 5: I feel like this lacks a normative statement about contextual rules. E.g. "A character with the derived property value CONTEXTJ or CONTEXTO (CONTEXTUAL RULE REQUIRED) MUST NOT be used unless an appropriate rule has been established and the context of the character is consistent with that rule." Regards, Florian Zeitz From yoshiro.yoneya@jprs.co.jp Wed Sep 11 03:10:21 2013 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 D855711E812D for ; Wed, 11 Sep 2013 03:10:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BXrQpe8p5Xxs for ; Wed, 11 Sep 2013 03:10:21 -0700 (PDT) Received: from off-send01.tyo.jprs.co.jp (off-send01.tyo.jprs.co.jp [IPv6:2001:df0:8:17::10]) by ietfa.amsl.com (Postfix) with ESMTP id 38BCB11E81FE for ; Wed, 11 Sep 2013 03:10:16 -0700 (PDT) Received: from off-sendsmg01.tyo.jprs.co.jp (off-sendsmg01.tyo.jprs.co.jp [172.18.8.32]) by off-send01.tyo.jprs.co.jp (8.13.8/8.13.8) with ESMTP id r8BAAEpl021870 for ; Wed, 11 Sep 2013 19:10:14 +0900 X-AuditID: ac120820-b7f196d00000167f-76-523041866c5c Received: from NOTE550 (off-cpu04.tyo.jprs.co.jp [172.18.4.14]) by off-sendsmg01.tyo.jprs.co.jp (Symantec Messaging Gateway) with SMTP id 0D.94.05759.68140325; Wed, 11 Sep 2013 19:10:14 +0900 (JST) Date: Wed, 11 Sep 2013 19:10:13 +0900 From: Yoshiro YONEYA To: precis@ietf.org Message-Id: <20130911191013.769e45e6cfadf7ed81b39817@jprs.co.jp> In-Reply-To: <20130904162606.a9058ca9af33636feb270c7f@jprs.co.jp> References: <20130828154613.9dadcee8c26f16af000854a9@jprs.co.jp> <20130904162606.a9058ca9af33636feb270c7f@jprs.co.jp> X-Mailer: Sylpheed 3.3.0 (GTK+ 2.10.14; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLIsWRmVeSWpSXmKPExsWyRoiFT7fN0SDI4Nx9dYtd3/+wOjB6LFny kymAMYrLJiU1J7MstUjfLoEr4/CBHSwF07gr1q57x9TA+Iaji5GTQ0LAROLcxp9MELaYxIV7 69lAbCGB44wSn1tsQWwWAVWJH7cOsoDYbAIGEr+W/QarFxEQlrh1eyEriC0sYCvRvnw5O4jN K+Ag8WbzdLA5nAKOEs8ff2eGmFku0THnOyvELguJC00dQPUcQPWCEn93CIOEmQW0JB7+usUC YctLbH87h3kCI98shKpZSKpmIalawMi8ilEmPy1Ntzg1L6U4N93AUK+kMl8vq6CoWC8ZRG9i BIcWh8IOxhmnDA4xCnAwKvHw3pPTDxJiTSwrrsw9xCjJwaQkyutnaxAkxJeUn1KZkVicEV9U mpNafIhRgoNZSYT3gSlQjjclsbIqtSgfJiXNwaIkznv8z5lAIYH0xJLU7NTUgtQimKwMB4eS BG+TA1CjYFFqempFWmZOCUKaiYMTZDgP0HAFkBre4oLE3OLMdIj8KUZJKXFeC5CEAEgiozQP rvcVozjQC8K8E0GyPMA0Adf1CmggE9DA7776IANLEhFSUg2MYVPXsgZXMG2cqW7977pM9/EO tquMQrqvyzbF7H4vbXR6xa8CtePikdPLag3mHip493yS3DsZPw7NmaLJC1i/JV7Z5id/TW1q MPMyv4fp2p/Plt4R1Oo/1cX7Z902aVv/iGdvK/1WJcboc1y43flVXiP2+Ou6YCUjSc6chTfn nZ79Wl+Ll3WzEktxRqKhFnNRcSIAQZsBgtACAAA= Subject: Re: [precis] WGLC: draft-ietf-precis-mappings-03.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2013 10:10:22 -0000 Dear all, This is final reminder. WC LC ends today. Until now, we received only a few comments to this documnet. If you already reviewed the document, please submit your feedback to the list. Regards, -- Marc & Yoneya, co-chairs On Wed, 4 Sep 2013 16:26:06 +0900 Yoshiro YONEYA wrote: > Dear all, > > This is reminder. WG LC will end next week. > Please review the document and give your feedback. > > Regards, > > -- Marc & Yoneya, co-chairs > > On Wed, 28 Aug 2013 15:46:13 +0900 Yoshiro YONEYA wrote: > > > Dear all, > > > > This message starts two weeks Working Group Last Call (WGLC) on > > draft-ietf-precis-mappings-03.txt (Mapping characters for PRECIS classes). > > > > Please review the document and send comments to the list (precis@ietf.org), > > the co-chairs (precis-chairs@tools.ietf.org), or the authors > > (draft-ietf-precis-mappings@tools.ietf.org) by the end of WGLC. > > > > The WGLC will end on Wednesday, Sep 11th. > > > > Regards, > > > > -- Marc & Yoneya, co-chairs > > > > _______________________________________________ > > precis mailing list > > precis@ietf.org > > https://www.ietf.org/mailman/listinfo/precis > > > > > > _______________________________________________ > precis mailing list > precis@ietf.org > https://www.ietf.org/mailman/listinfo/precis > > From alexey.melnikov@isode.com Wed Sep 11 05:46:57 2013 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 C1F6621E80C4 for ; Wed, 11 Sep 2013 05:46:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.475 X-Spam-Level: X-Spam-Status: No, score=-102.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ks+CDnb9vuhQ for ; Wed, 11 Sep 2013 05:46:56 -0700 (PDT) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1289021E80FC for ; Wed, 11 Sep 2013 05:46:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1378903613; d=isode.com; s=selector; i=@isode.com; bh=ViYSYKJaS6Pz3Y2OfXM52VEqImRqUE7M745Kk3k6frg=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=X8xf9xq5irewD0/sEnyAo4toczqD++HfE/t9nsZQobbG3N6wfGIunvOXijbP/O8cOZ4Qyz xWhLWsm1EUHy892sD5gWkqLHo4SB8g51CSr+B6upRsbB7CtrNXnVSkCm2325NdzP5WWRue EHLcVHArGwjdnqW+xjyhg5D44xJtfZk=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 11 Sep 2013 13:46:53 +0100 Message-ID: <5230663E.7010606@isode.com> Date: Wed, 11 Sep 2013 13:46:54 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 To: precis@ietf.org References: <20130828154613.9dadcee8c26f16af000854a9@jprs.co.jp> In-Reply-To: <20130828154613.9dadcee8c26f16af000854a9@jprs.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [precis] WGLC: draft-ietf-precis-mappings-03.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2013 12:46:57 -0000 On 28/08/2013 07:46, Yoshiro YONEYA wrote: > Dear all, > > This message starts two weeks Working Group Last Call (WGLC) on > draft-ietf-precis-mappings-03.txt (Mapping characters for PRECIS classes). > > Please review the document and send comments to the list (precis@ietf.org), > the co-chairs (precis-chairs@tools.ietf.org), or the authors > (draft-ietf-precis-mappings@tools.ietf.org) by the end of WGLC. > > The WGLC will end on Wednesday, Sep 11th. I tend to agree with Peter's comments. In addition to that I have one nit: The References section should be split into Normative References (documents required to understand or implement this one) and Informative References, even though this is an Informational document. From simon@josefsson.org Wed Sep 11 10:39:18 2013 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 275B421F9DD5; Wed, 11 Sep 2013 10:39:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id am7Qe1vo5eEn; Wed, 11 Sep 2013 10:39:17 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) by ietfa.amsl.com (Postfix) with ESMTP id 254B521F99FA; Wed, 11 Sep 2013 10:39:12 -0700 (PDT) Received: from latte.josefsson.org ([38.111.151.140]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id r8BHcsa0005363 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 11 Sep 2013 19:39:01 +0200 From: Simon Josefsson To: Nico Williams References: <51FEEC99.1020901@stpeter.im> <52090F96.30700@stpeter.im> <522E5CAA.5010902@stpeter.im> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:130911:precis@ietf.org::pmZoj4jn9s3KfZUb:Yzz X-Hashcash: 1:22:130911:kitten@ietf.org::V7In9ys8HsRFb3nD:35zv X-Hashcash: 1:22:130911:stpeter@stpeter.im::mFPkDl4896RoaJTC:3hSf X-Hashcash: 1:22:130911:nico@cryptonector.com::pKjQKysJ/Q5E4zeb:3T7P Date: Wed, 11 Sep 2013 10:38:48 -0700 In-Reply-To: (Nico Williams's message of "Tue, 10 Sep 2013 09:06:20 -0500") Message-ID: <87bo3zi7h3.fsf@latte.josefsson.org> User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97.8 at duva.sjd.se X-Virus-Status: Clean Cc: "kitten@ietf.org" , "precis@ietf.org" Subject: Re: [precis] [kitten] Fwd: Re: I-D Action: draft-ietf-precis-saslprepbis-04.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2013 17:39:18 -0000 Nico Williams writes: >> In version -04, based on PRECIS WG discussion, we changed that to: >> >> 3. Uppercase and titlecase characters SHOULD be mapped to their >> lowercase equivalents (not doing so can lead to false positives >> during authentication and authorization, as described in >> [RFC6943]). >> > > This is the third time, I think, that I've had to voice my vehement > objections to this. I thought we were done the second time. I believe > SASL applications and mechanisms MUST NOT do the above, not on the client > side, and that the server should be allowed to do what it wishes. If the text above would have any bearing on SASL implementations (which isn't clear to me), I would strongly agree with you that the text above is a Bad Idea. Generally, I believe the use-case of I18N of username & password have special requirements that have been ignored by the PRECIS WG because the username/password requirements are sometimes conflicting with other goals of PRECIS and there doesn't seem to be enough interest to cater to both communities at the same time. Perhaps that is fine (I understand PRECIS wants to publish), but then it should be made clear that PRECIS will have no immediate bearing on SASLprepNG. /Simon From stpeter@stpeter.im Wed Sep 11 11:04:15 2013 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 0488111E80D2; Wed, 11 Sep 2013 11:04:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qObl8-gakgar; Wed, 11 Sep 2013 11:04:10 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 10F8221F9CB6; Wed, 11 Sep 2013 11:04:09 -0700 (PDT) Received: from ergon.local (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 3EAEC206F2; Wed, 11 Sep 2013 12:08:37 -0600 (MDT) Message-ID: <5230B096.4090303@stpeter.im> Date: Wed, 11 Sep 2013 12:04:06 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Nico Williams References: <51FEEC99.1020901@stpeter.im> <52090F96.30700@stpeter.im> <522E5CAA.5010902@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "kitten@ietf.org" , "precis@ietf.org" Subject: Re: [precis] [kitten] Fwd: Re: I-D Action: draft-ietf-precis-saslprepbis-04.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2013 18:04:15 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/10/13 8:06 AM, Nico Williams wrote: > On Monday, September 9, 2013, Peter Saint-Andre wrote: > > -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > > Dear KITTEN WG, > > Your feedback would be appreciated on this I-D. This version > incorporates the input that Alexey and I received from folks here, > as well as discussion at the PRECIS WG session in Berlin: > > http://www.ietf.org/proceedings/87/minutes/minutes-87-precis > > One question in particular regarding preparation of usernames, > especially for Nico since he suggested the original text... > > Version -03 said: > > 3. Uppercase and titlecase characters MAY be mapped to their > lowercase equivalents. > > In version -04, based on PRECIS WG discussion, we changed that to: > > 3. Uppercase and titlecase characters SHOULD be mapped to their > lowercase equivalents (not doing so can lead to false positives > during authentication and authorization, as described in > [RFC6943]). > > The rationale was that we really don't want to give people a gun > to shoot themselves with. Some folks in the PRECIS WG session > leaned even to "MUST" here, but SHOULD with an explanation of the > consequences was a compromise position. In any case, the original > MAY seemed way too weak to folks in the PRECIS WG. Please let us > know if you have grave concerns about the text in -04. > > > This is the third time, I think, that I've had to voice my > vehement objections to this. I thought we were done the second > time. Hi Nico, I don't think vehemence is needed. We have some different perspectives, and we're trying to find common ground. Would you perhaps have time to listen to the recording of the PRECIS WG session in Berlin? Also, would you be available for a phone conference on this topic so that we can work through it in closer to real time? Or might you be coming to the IETF meeting in Vancouver? I'm out of time for the moment but I will reply at greater length soon. (I include the rest of your message below because I have not yet seen it arrive on the PRECIS list....) > I believe SASL applications and mechanisms MUST NOT do the above, > not on the client side, and that the server should be allowed to do > what it wishes. The only exception is for password (and salt) > processing in DIGEST/SCRAM-like mechanisms where keys are derived > from passwords on the client- (and server-) sides, therefore > canonical password representations are desirable, and even then, > case folding would be nothing short of -- and I must be utterly > frank here-- stupid, as it means dropping entropy needlessly. > > The argument I made before was that we need to distinguish between > query, display, and storage strings. If a username must be > canonicalized then this should be done where it must be used as a > databased/directory lookup key or as a cryptographic salt (where > roughly the same considerations as for passwords used to derive > keys apply). We should delay canonicalization as much as possible > so as to support the server operator's choice of canonicalization. > I've mentioned before that many online games allow all sorts of > username forms that we'd consider silly in an enterprise > environment, but in online gaming they are quite desirable as a > form of styling. Let's not put a straightjacket on users of this > string preparation -- let each operator pick their poison as much > as possible. > > The RFC6943 reference should be more specific. What specific > confusion cases are we worried about? > > Please have this argument on the KITTEN WG list. I'm cc'ing > precis@ietf.org just this once, and I will > not subscribe to it. We've had at least two debates on > SASLprep-bis at KITTEN. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSMLCWAAoJEOoGpJErxa2pcm0P/0ZP8jvkfVRJPmoqYn8wUIBm v+R4nJFlCDsrjpI/RowNhbovYb2pdbRfaAeR+P3Z1FDLe/vRb2itau5v3Dqp/sC1 rAEsddMZI1IAEDLQL5y2w8W8g9kIyd8qQ//oMoLjflYjO2yhM/QFlEvhSDVyanVn UdZ+m2VWZWupGfhmM+xtFyQ1VS9JjzOK6OI0z6eEs3laIZPbi9FFBUZahMeV180q P3chjmq3OYn5wAYCBlTNlp+IKQbB2F/whobn8n668oRqx1MrPpu11nwJQAVeLQiv th3pCicWw7EbLePPu9lRD88n0n+aWfDvJfffeKUE/aARcYHbsWakj8U0+1p+T8AH r8sTVRMW7YdKQiFqx2ftDfGV+GLUy6lsJa5/ah6KqWqHWxZnHVOAnuW950/y3Oyq lQEDMTwl0I+FEdqsWGwNih+XzDjF4ZmGKyENqejmUPXgvDF8c0Bf5NqBxXdtm1qB apbbPcJgWiXIWFYvwjRPfs0NTs06fmbvf+QF34ylf7UihS6D4o8w1SXiKn/FUwOl VTH6FOlaYBoK/S3ZVFlFuC9cibe/c/EW2kAVFWdgTqt6Dl/A39Bor5BplU9zy3K9 Pm0RHDH776uOMIzhYKK4x//1oE318BHwMR4+qPA65u7wWREjMzZ0ETkPxMwioMVf tFcRAQsgxXCXJTqdMwwa =RXpe -----END PGP SIGNATURE----- From stpeter@stpeter.im Wed Sep 11 11:07:41 2013 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 BB8CA11E8105; Wed, 11 Sep 2013 11:07:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L1m1-tRur+kN; Wed, 11 Sep 2013 11:07:36 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id F34B521E808E; Wed, 11 Sep 2013 11:07:35 -0700 (PDT) Received: from ergon.local (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B141941640; Wed, 11 Sep 2013 12:12:03 -0600 (MDT) Message-ID: <5230B165.2030202@stpeter.im> Date: Wed, 11 Sep 2013 12:07:33 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Simon Josefsson References: <51FEEC99.1020901@stpeter.im> <52090F96.30700@stpeter.im> <522E5CAA.5010902@stpeter.im> <87bo3zi7h3.fsf@latte.josefsson.org> In-Reply-To: <87bo3zi7h3.fsf@latte.josefsson.org> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "kitten@ietf.org" , Nico Williams , "precis@ietf.org" Subject: Re: [precis] [kitten] Fwd: Re: I-D Action: draft-ietf-precis-saslprepbis-04.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2013 18:07:42 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/11/13 11:38 AM, Simon Josefsson wrote: > Nico Williams writes: > >>> In version -04, based on PRECIS WG discussion, we changed that >>> to: >>> >>> 3. Uppercase and titlecase characters SHOULD be mapped to >>> their lowercase equivalents (not doing so can lead to false >>> positives during authentication and authorization, as described >>> in [RFC6943]). >>> >> >> This is the third time, I think, that I've had to voice my >> vehement objections to this. I thought we were done the second >> time. I believe SASL applications and mechanisms MUST NOT do the >> above, not on the client side, and that the server should be >> allowed to do what it wishes. > > If the text above would have any bearing on SASL implementations > (which isn't clear to me), I would strongly agree with you that the > text above is a Bad Idea. > > Generally, I believe the use-case of I18N of username & password > have special requirements that have been ignored by the PRECIS WG > because the username/password requirements are sometimes > conflicting with other goals of PRECIS and there doesn't seem to be > enough interest to cater to both communities at the same time. > Perhaps that is fine (I understand PRECIS wants to publish), but > then it should be made clear that PRECIS will have no immediate > bearing on SASLprepNG. Hi Simon, Actually that text comes from draft-ietf-precis-saslprepbis: http://tools.ietf.org/html/draft-ietf-precis-saslprepbis-04#section-4.2 As I noted to Nico, we need to get this right and we need to take the time to do so. Alexey and I are committed to doing that, and we'll find a way to make it happen. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSMLFkAAoJEOoGpJErxa2pfv4P/Roq3J1EiaVyQVBErahCX8Lz b1HoYUgq0DfMYcTQtf69U8+MA9CFklaJiPOnaiWwZ0Wy7cXNTMMvNSBbDOFkbpiS y0pgc6Y2mel2WRwlAgAjX45SB4cfSiAEToFeG8LBST8a5hpd5Bd6zTJFaY/vOQFX e0yR99BpuPKy7DH9VGauWxFMGDOmTWo42YmBkcREwPbuuqdGttFgOqSRUxPDsQiS VNdkfWygOKunZtRa5iV6dBsloCcZLuuQBjD7iw2tjeP6cEI85mKB+QruBY4V5n/0 Bff1YkwKAaKeR2GQfz1UZMqzFy/1Ko9SmoXiW+Cvt/utY1eqqD+9VPN5lg95IU4u GrgxBT38DJmhvR0FuaFb6QKJDRVPWZG9mppj7Y8Qt/LZeZPvyvyDLKr1TBf7iMKz QLU0Osak+2YGTVXKAFCv30522IgVMcTH54GSX99Ej+CDYbJEiqK9F1FmZBl1wNko Pn9eHF31frZY4DaiLSQMyEws0p2a4CvqmBU03EPKE62J/tR7EoZSgB8cv2Dkuh1O tAvZQ4cAHR2LLl3r7nHGcuFkqQiXACh+vYC52Xogl+GxfMFfGlvooKd80TakuJt9 9OYm0ojltWihVL+bJTriIAB3ZjtxkmPMaXKNNHya7emX9tOX2MQaYS8edpwPTpL/ LTOHtJGqsBM+k2LcaZ7Z =Gat7 -----END PGP SIGNATURE----- From florob@babelmonkeys.de Wed Sep 11 11:17:26 2013 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 8933211E80D7; Wed, 11 Sep 2013 11:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.308 X-Spam-Level: X-Spam-Status: No, score=-1.308 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MISSING_HEADERS=1.292, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vk2cs050BQAk; Wed, 11 Sep 2013 11:17:26 -0700 (PDT) Received: from babelmonkeys.de (babelmonkeys.de [IPv6:2a02:d40:3:1:10a1:5eff:fe52:509]) by ietfa.amsl.com (Postfix) with ESMTP id EBF5011E8112; Wed, 11 Sep 2013 11:17:25 -0700 (PDT) Received: from [2001:4dd0:ff00:9359:3e97:eff:fe0f:f4d] by babelmonkeys.de with esmtpsa (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1VJp05-0007lK-D6; Wed, 11 Sep 2013 20:18:49 +0200 Message-ID: <5230B3B3.3040805@babelmonkeys.de> Date: Wed, 11 Sep 2013 20:17:23 +0200 From: Florian Zeitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130806 Thunderbird/17.0.8 MIME-Version: 1.0 References: <51FEEC99.1020901@stpeter.im> <52090F96.30700@stpeter.im> <522E5CAA.5010902@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: "kitten@ietf.org" , "precis@ietf.org" Subject: Re: [precis] [kitten] Fwd: Re: I-D Action: draft-ietf-precis-saslprepbis-04.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2013 18:17:26 -0000 Am 10.09.2013 16:06, schrieb Nico Williams: > This is the third time, I think, that I've had to voice my vehement > objections to this. I thought we were done the second time. I believe > SASL applications and mechanisms MUST NOT do the above, not on the > client side, and that the server should be allowed to do what it wishes. > The only exception is for password (and salt) processing in > DIGEST/SCRAM-like mechanisms where keys are derived from passwords on > the client- (and server-) sides, therefore canonical password > representations are desirable, and even then, case folding would be > nothing short of -- and I must be utterly frank here-- stupid, as it > means dropping entropy needlessly. > > The argument I made before was that we need to distinguish between > query, display, and storage strings. If a username must be > canonicalized then this should be done where it must be used as a > databased/directory lookup key or as a cryptographic salt (where roughly > the same considerations as for passwords used to derive keys apply). We > should delay canonicalization as much as possible so as to support the > server operator's choice of canonicalization. I've mentioned before > that many online games allow all sorts of username forms that we'd > consider silly in an enterprise environment, but in online gaming they > are quite desirable as a form of styling. Let's not put a > straightjacket on users of this string preparation -- let each operator > pick their poison as much as possible. > I'm a bit confused. My impression is that the draft already contains text very much in that spirit: « SASL mechanisms that directly re-use this profile MUST specify whether and when case mapping is to be applied to authentication identifiers. SASL mechanisms SHOULD delay any case mapping to the last possible moment, such as when doing a lookup by username, username comparisons, or generating a cryptographic salt from a username. In keeping with RFC4422, SASL mechanisms are not to apply this or any other profile to authorization identifiers. » While online games might not always want case folded strings, I doubt having two usernames that differ only in case is ever desirable. From joseph.yee@gmail.com Wed Sep 11 19:06:21 2013 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 6A80311E8213 for ; Wed, 11 Sep 2013 19:06:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bnSkJ4haT3UP for ; Wed, 11 Sep 2013 19:06:20 -0700 (PDT) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id C9A9711E81EA for ; Wed, 11 Sep 2013 19:06:20 -0700 (PDT) Received: by mail-ie0-f174.google.com with SMTP id k10so12308509iea.5 for ; Wed, 11 Sep 2013 19:06:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vusyBO3EIClYxLwqFhLlaA7nz0VxXaDwgpGmCgUZic8=; b=V8QaPDyd5PgwKmfDJnjcbjP8vpg9hpITT2GsULdJAbKuuj1B5uQ0XQwYXTyRqZihJT GfFa31j5oAs15AIhgHnVPbdjizRbalC8+u1qWpULcTrOkZzXqWnRYOS3+s8BANieKadh LLjCVCDUNGHtuNv0zcRRChDNYKMGKTEvI+5wvQleTKh9VutMVOnuOrA3doAUptstGk+4 ssg1f9jOE5SN83KhNBGRrJ2pmgJHaWhUROzNH1eCK1/N6PORs5VvdGNtUYGBNejh2ue/ 8tBp0zJLqqtmJbl7hO8eIbmfoNr3o+2hRQftFYtSuygp3MBYbCu6Gb/odzQ+Co8Rchxc vZFQ== MIME-Version: 1.0 X-Received: by 10.50.102.99 with SMTP id fn3mr12674649igb.5.1378951580434; Wed, 11 Sep 2013 19:06:20 -0700 (PDT) Received: by 10.64.170.101 with HTTP; Wed, 11 Sep 2013 19:06:20 -0700 (PDT) In-Reply-To: <20130904162558.7fad8dd5d2304591166dd37a@jprs.co.jp> References: <20130828154603.a94201dea74f29229b4767b2@jprs.co.jp> <20130904162558.7fad8dd5d2304591166dd37a@jprs.co.jp> Date: Wed, 11 Sep 2013 22:06:20 -0400 Message-ID: From: Joseph Yee To: Yoshiro YONEYA Content-Type: multipart/alternative; boundary=e89a8ffbae3f1d45f004e6262fa0 Cc: precis@ietf.org Subject: Re: [precis] WGLC: draft-ietf-precis-framework-09.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 02:06:21 -0000 --e89a8ffbae3f1d45f004e6262fa0 Content-Type: text/plain; charset=UTF-8 On Wed, Sep 4, 2013 at 3:25 AM, Yoshiro YONEYA wrote: > Dear all, > > This is reminder. WG LC will end next week. > Please review the document and give your feedback. > > Regards, > > -- Marc & Yoneya, co-chairs > > On Wed, 28 Aug 2013 15:46:03 +0900 Yoshiro YONEYA < > yoshiro.yoneya@jprs.co.jp> wrote: > > > Dear all, > > > > This message starts two weeks Working Group Last Call (WGLC) on > > draft-ietf-precis-framework-09.txt (PRECIS Framework: Preparation and > > Comparison of Internationalized Strings in Application Protocols). > > > > Please review the document and send comments to the list ( > precis@ietf.org), > > the co-chairs (precis-chairs@tools.ietf.org), or the authors > > (draft-ietf-precis-framework@tools.ietf.org) by the end of WGLC. > > > > The WGLC will end on Wednesday, Sep 11th. > > > > Reviewed the draft, think the approach is good. Just one minor comment. Same as Florian, had the 'hmm' reaction when reading about directionality and application behaviour at Section 3.1. It seems that the only application behaviour is permitted pattern. It doesn't deal with visual appearance I believed. Maybe replace 'application behaviour' with 'permitted patther of the string' (or 'allowed combination of the string')? Best, Joseph --e89a8ffbae3f1d45f004e6262fa0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Wed, Sep 4, 2013 at 3:25 AM, Yoshiro YONEYA <yoshiro.yoneya@jpr= s.co.jp> wrote:
Dear all,

This is reminder. =C2=A0WG LC will end next week.
Please review the document and give your feedback.

Regards,

-- Marc & Yoneya, co-chairs

On Wed, 28 Aug 2013 15:46:03 = +0900 Yoshiro YONEYA <yoshi= ro.yoneya@jprs.co.jp> wrote:

> Dear all,
>
> This message starts two weeks Working Group Last Call (WGLC) on
> draft-ietf-precis-framework-09.txt (PRECIS Framework: Preparation and<= br> > Comparison of Internationalized Strings in Application Protocols).
>
> Please review the document and send comments to the list (precis@ietf.org),
> the co-chairs (precis-= chairs@tools.ietf.org), or the authors
> (draft-i= etf-precis-framework@tools.ietf.org) by the end of WGLC.
>
> The WGLC will end on Wednesday, Sep 11th.
>


Reviewed the draft, think = the approach is good.=C2=A0 Just one minor comment.

Same = as Florian, had the 'hmm' reaction when reading about directionalit= y and application behaviour at Section 3.1.=C2=A0 It seems that the only ap= plication behaviour is permitted pattern.=C2=A0 It doesn't deal with vi= sual appearance I believed.=C2=A0 Maybe replace 'application behaviour&= #39; with 'permitted patther of the string' (or 'allowed combin= ation of the string')?

Best,
Joseph



<= div>

--e89a8ffbae3f1d45f004e6262fa0-- From nico@cryptonector.com Wed Sep 11 21:02:30 2013 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 63B0921F9E04; Wed, 11 Sep 2013 21:02:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vbhUx8zp8Aib; Wed, 11 Sep 2013 21:02:25 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id 77F1C21F9D92; Wed, 11 Sep 2013 21:02:25 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTP id 2AEA821DE65; Wed, 11 Sep 2013 21:02:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=QKK8Llcr+ibG/P5wT47J tkBl4/A=; b=sHZBNJWyyuM5bMlGuGXBQquWUgPM0fZWtmMCNqkSUDT7HZimKfPA l/gmlErsgUAyJz7ET0XN7FEP1y1zm0SxYVd49ZmbVCk82vKg62EUa/TQW7w8dxmM w+06CEuyHsJJ86nbB2x0ijBhIUHoxFCa+Zi73zW38lZ0PvzW7MKGcmo= Received: from mail-we0-f169.google.com (mail-we0-f169.google.com [74.125.82.169]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTPSA id A32D621DE57; Wed, 11 Sep 2013 21:02:24 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id t60so8849701wes.14 for ; Wed, 11 Sep 2013 21:02:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Y+vqcwtchrJSNhZJLSpB0c3PHKx8+7ZeSbzrhYYDJNA=; b=labGa/sdAJlkUHuKMJU0RzkKizDo+U74amSNzs0iZ9Id18+RysOWY0ahxUGzYdthcW yUX3thcj3uHaC2P5M2pp2Gu3PBUEczMF5edDMcnIf/WJUqNkGB5CPBkpzgjFwbXTzs6/ gnGuVWwNYSxUGK6yU00i88I3X7X6yfsQ2GZQKYQzUhPEUhgLosTU5LcO8lKdbAW2haOU E9zCoFLGAYUiht7zSu9kh1+EGh+85Q/rqnyroCE0hd9CS9MlBavja8E2xSABGEeUDsZc pXnIU4QaKTlBD6NXE8H4GVPClkWORh/TYAIt1mw3kgUNf655C4U+hNZel+FcedvOBvSi QDpA== MIME-Version: 1.0 X-Received: by 10.180.206.244 with SMTP id lr20mr3943327wic.45.1378958541797; Wed, 11 Sep 2013 21:02:21 -0700 (PDT) Received: by 10.216.240.70 with HTTP; Wed, 11 Sep 2013 21:02:21 -0700 (PDT) In-Reply-To: <5230B096.4090303@stpeter.im> References: <51FEEC99.1020901@stpeter.im> <52090F96.30700@stpeter.im> <522E5CAA.5010902@stpeter.im> <5230B096.4090303@stpeter.im> Date: Wed, 11 Sep 2013 23:02:21 -0500 Message-ID: From: Nico Williams To: Peter Saint-Andre Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" , "precis@ietf.org" Subject: Re: [precis] [kitten] Fwd: Re: I-D Action: draft-ietf-precis-saslprepbis-04.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 04:02:30 -0000 On Wed, Sep 11, 2013 at 1:04 PM, Peter Saint-Andre wrote: > On 9/10/13 8:06 AM, Nico Williams wrote: >> On Monday, September 9, 2013, Peter Saint-Andre wrote: >> This is the third time, I think, that I've had to voice my >> vehement objections to this. I thought we were done the second >> time. > > Hi Nico, I don't think vehemence is needed. We have some different > perspectives, and we're trying to find common ground. I misread anyways, then overreacted. Sorry about that. I have no objection to telling people that they should (not must) treat usernames case-insensitively. They should be told to preserve case as much as possible though, if they allow mixed-case usernames at all. Also, if this is a recommendation for people *deploying* or people designing mechanisms, then the recommendation shouldn't use RFC2119 language (since it's not a recommendation as to what an implementation should do. Finally, if the only goal is to prevent confusion (thinking that two usernames are equivalent when they are not), shouldn't the prescription be to check for case-insensitive collisions at *enrollment* time? I would think so -- then the recommendation would not apply to, say, mechanism implementors (since SASL doesn't deal with enrollment) but to system integrators -- recommendations and requirements about enrollment could be stated in RFC2119 language. So, there's some subtle things here to get right. Also, if the goal is to be case-insensitive then that should be stated. As should be case-preservation. I'm not sure that specifying the nitty gritty of how case-insensitivity is obtained matters much here. > Would you perhaps have time to listen to the recording of the PRECIS > WG session in Berlin? Sure. I'll take a listen. > Also, would you be available for a phone conference on this topic so > that we can work through it in closer to real time? Or might you be > coming to the IETF meeting in Vancouver? I'm thinking I have to go to Vancouver, but as usual it probably won't be for the whole week. My primary interests now lie in KITTEN and HTTPauth WGs. Nico -- From t.nemo10@kmd.keio.ac.jp Tue Sep 17 02:56:43 2013 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 90DC821F9EDB for ; Tue, 17 Sep 2013 02:56:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.155 X-Spam-Level: X-Spam-Status: No, score=0.155 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FRT_BELOW2=2.154, GB_I_LETTER=-2, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5HqxQ9TlT7fE for ; Tue, 17 Sep 2013 02:56:38 -0700 (PDT) Received: from mail.kmd.keio.ac.jp (mail.kmd.keio.ac.jp [IPv6:2001:200:167:2e90::164]) by ietfa.amsl.com (Postfix) with ESMTP id 71C4111E83E0 for ; Tue, 17 Sep 2013 02:56:34 -0700 (PDT) Received: from [IPv6:2001:200:167:2ec1:e149:e026:dcf8:13ac] (unknown [IPv6:2001:200:167:2ec1:e149:e026:dcf8:13ac]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.kmd.keio.ac.jp (Postfix) with ESMTPSA id 4B8D280554; Tue, 17 Sep 2013 18:56:29 +0900 (JST) Content-Type: multipart/signed; boundary="Apple-Mail=_46A253EF-688E-4E44-BBB1-98915C01A95C"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Takahiro Nemoto In-Reply-To: <5227A979.7050403@stpeter.im> Date: Tue, 17 Sep 2013 18:56:28 +0900 Message-Id: References: <5227A979.7050403@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1508) Cc: "precis@ietf.org" Subject: Re: [precis] local case mapping X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 09:56:43 -0000 --Apple-Mail=_46A253EF-688E-4E44-BBB1-98915C01A95C Content-Type: multipart/alternative; boundary="Apple-Mail=_FBD5273B-B7E3-4A42-A7EF-3AED4E1FBA20" --Apple-Mail=_FBD5273B-B7E3-4A42-A7EF-3AED4E1FBA20 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Peter-san and Alexey-san Thank you for your thorough review and helpful comment. Let me respond to the concerns that you raised in the previous email. I'll try to simplify the mappings document that I wrote according to = your suggestion. Local Case Mapping is targeted towards special characters that depends = on the language. Also, the term "Case Folding" that I used in the mappings document = refers=20 to the "Common Case Folding" that is mentioned in the CaseFolding.txt = file. The targets of this "Local Case Mapping" are the following characters = which are described in the Language-Sensitive Mappings section in the SpecialCasing.txt = file. (Language-Sensitive Mappings are characters whose full case mappings=20 depend on language and perhaps also context.) For Turkish and Azeri: ; ; ; means the alpha-2 codes in [ISO.3166-1]. tr; 0307; ; COMBINING DOT ABOVE tr; 0130; 0069; LATIN CAPITAL LETTER I WITH DOT ABOVE tr; 0049; 0131; LATIN CAPITAL LETTER I az; 0307; ; COMBINING DOT ABOVE az; 0130; 0069; LATIN CAPITAL LETTER I WITH DOT ABOVE az; 0049; 0131; LATIN CAPITAL LETTER I For Lithuanian is at the end of a sentence. In the CaseFolding.txt, it is written that "Final Sigma" (as written = bellow) Case-Folds=20 to the "Lowercase Sigma" as Common Case Folding. So let's say if the = "Uppercase Sigma"=20 that comes at the end of a sentence is converted to "Final Sigma" using = Local Case Mapping,=20 there is no meaning. Because of this, I would not put Final Sigma as one = of the targets=20 for Local Case Mapping currently. In CaseFolding.txt: 03C2; C; 03C3; # GREEK SMALL LETTER FINAL SIGMA By the way, I investigated Lithuanian which are described in = SpecialCasing.txt file. And I found some problems. I would like to ask you whether Lithuanian = should be considered as a target for local case mapping as open issues. In the Lithuanian language, there are some characters that are = unassigned in the Unicode.=20 For this reason, when a uppercase characters with accent (as mentioned = in SpecialCasing.txt)=20 is mapped into lowercase characters, the characters of the Italian = language are used instead=20 of the formal Lithuanian language expression. For example, the character =C3=AC; 00CC (i with a grave accent) is being = used in both the Lithuanian and Italian language. In Italian language, this lowercase character is expressed as (=C3=AC; = 00EC: Grave accent on dotless i),=20 whereas in Lithuanian language it is (i=CC=87=CC=80; 0069 0307 0300: = Grave accent on dotted i), differentiating both characters. However, in the input system of PC and smartphones that use the = Lithuanian language,=20 Italian character =C3=AC(00EC) substitutes that role. The difference of 00CC in CaseFolding.txt and SpecialCasing.txt is as = following: CaseFolding.txt -> 00CC; C; 00EC; # LATIN CAPITAL LETTER I WITH GRAVE SpecialCasing.txt -> 00CC; 0069 0307 0300; LATIN CAPITAL LETTER I WITH = GRAVE Looking at the comparison between Lithuanian strings that contain 00CC = and 00EC,=20 when they are local case mapped using the current definition,=20 and then followed by case mapping, they become different strings. So I'd like to hear your comment about these. I have two proposals for this problem.=20 1) In the case of localized Lithuanian language, 00EC is mapped into = 0069;0307;0300 using local case mapping. 2) In the future, as there is be a possibility that the combined characters = 0069;0307;0300 into 1 character is registered in the Unicode, local case = mapping doesn't need to care about it. Which proposal is more preferable? Please let me know what you think. Regards, Nemo -- Takahiro Nemoto t.nemo10@kmd.keio.ac.jp On 2013/09/05, at 6:43, Peter Saint-Andre wrote: > As mentioned, I find Section 2.3 of draft-ietf-precis-mappings hard to > understand. This message is a bit long because I was puzzling over > things as I wrote it. I hope it's not too rambling. >=20 > A relatively minor point: there's a bit of confusion between > locale-dependent mapping and context-dependent mapping. For instance: >=20 > Local case mapping is case folding that depends on language and > context. For example, the mapping of LATIN CAPITAL LETTER I = (U+0049) > depends on the language context of the user: if the language is > Turkish (or one of several other languages), the character should be > mapped into LATIN SMALL LETTER DOTLESS I (U+0131) as this = character's > lower case equivalent. >=20 > The first sentence is confusing because it says that local case = mapping > depends on language *and* context. I think we mean language *or* = context > (or, even better, locale or context, since the Unicode standard talks > about "locale-dependent case mapping"). Also, the use of "case = folding" > might not be quite right here, because that term has a very specific > meaning (e.g., Chapter 5.18 of the Unicode standard says things like > "The Unicode case folding algorithm is defined to be simpler and more > efficient than case mappings."). In the next sentence, the phrase > "language context" will cause even more confusion. :-) I think > "language" is enough here. Also I think it would be helpful to add an > example of a context-dependent mapping (but see below!). >=20 > Thus I suggest: >=20 > Local case mapping depends on locale or context. As an example of > locale-dependent mapping, LATIN CAPITAL LETTER I (U+0049) is > normally mapped to LATIN SMALL LETTER I ((U+0069); however, if the > language is Turkish (or one of several other languages), then the > character should be mapped to LATIN SMALL LETTER DOTLESS I (U+0131). > As an example of context-dependent mapping, GREEK CAPITAL LETTER > SIGMA (U+03A3) is mapped to GREEK SMALL LETTER SIGMA (U+03C3) if it > is followed by another letter, but is mapped to GREEK SMALL LETTER > FINAL SIGMA (U+03C2) if it is not followed by another letter. >=20 > So that's the first paragraph. :-) >=20 > The second paragraph says: >=20 > Local case mapping targets only characters that > get two different results to perform just casefolding that is = defined > in the Casefolding.txt [Casefolding] and perform special casefolding > that is defined in the Specialcasing.txt then casefolding, because > PRECIS framework have casefolding. >=20 > (Nit: The file names are actually CamelCase in the UCD, i.e., > CaseFolding.txt and SpecialCase.txt.) >=20 > That's a long sentence. I suggest breaking it up (I started to do that > but then bigger questions arose). >=20 > As I understand it "just casefolding" isn't really defined in the > CaseFolding.txt file, because four kinds of casefolding are specified > there: (1) common case folding, (2) full case folding, (3) simple case > folding, and (4) Turkic mappings for uppercase I and dotted uppercase = I. >=20 > It's not clear to me exactly what draft-ietf-precis-mappings is > recommending here. Is it saying that local case mapping applies (a) = when > there is a difference between common case mapping and anything else, = (b) > when there is no common case folding, (c) when there are multiple > possible case foldings, or (d) something else? >=20 > As examples: >=20 > 1. Common case folding handles things like LATIN CAPITAL LETTER A > (U+0041) to LATIN SMALL LETTER A (U+0061). There are no alternative > mappings for this character and it's handled by UnicodeData.txt. >=20 > 2. Full case folding can result in mapping to multiple characters, = such > as LATIN CAPITAL LETTER SHARP S (U+1E9E) to LATIN SMALL LETTER S > (U+0073) + LATIN SMALL LETTER S (U+0073). >=20 > 3. Simple case folding always maps to a single character, such as = LATIN > CAPITAL LETTER SHARP S (U+1E9E) to LATIN SMALL LETTER SHARP S = (U+00DF). >=20 > (As we see, there are several possible case foldings for U+1E9E.) >=20 > 4. LATIN CAPITAL LETTER I commonly maps to LATIN SMALL LETTER I but > under Turkic mappings it maps to LATIN SMALL LETTER DOTLESS I. >=20 > The UnicodeData.txt file specifies one-to-one case mappings that are > independent of language, locale, and context. Thus it doesn't cover: >=20 > - full case folding (e.g., in UnicodeData.txt U+1E9E is mapped to > U+00DF, not U+0073 U+073) since that's not one-to-one >=20 > - context-specific mappings such as uppercase Greek sigma to Greek = final > sigma when followed by a space >=20 > - locale-specific mappings such as LATIN CAPITAL LETTER I to LATIN = SMALL > LETTER DOTLESS I in Turkic languages >=20 > I think we need to be clear about what we're trying to accomplish = here. > Are we actually addressing all mappings that are not handled by the > UnicodeData.txt file (i.e., everything except "common case folding" as > specified by the CaseFolding.txt file)? It seems that way to me (i.e., > we need to say something about context-specific mappings for sure, and > probably also case folding that isn't one-to-one such as LATIN CAPITAL > SHARP S to ss), but that's not what draft-ietf-precis-mappings says = now... >=20 > There are two types casefoldings defined as Unconditional Mappings > and Conditional Mappings in the Specialcasing.txt file. Conditional > mappings have Language-Insensitive Mappings that target characters > whose full case mappings do not depend on language, but do depend on > context. Language-Sensitive Mappings that these are characters = whose > full case mappings depend on language and perhaps also context. >=20 > Of these mappings, characters with Unconditional Mappings or with > Language-Insensitive Mappings in Conditional Mappings target are > mapped into same codepoint(s) with just casefolding or special > casefolding then casefolding. But characters with = Language-Sensitive > Mappings in Conditional Mappings targets are mapped into different > codepoints. Therefore this document defines characters that are a > part of characters of Lithuanian(lt), Turkish(tr) and > Azerbaijanian(az) that Language-Sensitive Mappings targets as = targets > for local case mapping. >=20 > As I read that text, it says: >=20 > 1. "Local case mapping" applies only to the Language-Sensitive = Mappings > (one division of the Conditional Mappings) from SpecialCasing.txt >=20 > 2. "Local case mapping" does not apply to the Language-Insensitive > Mappings from SpecialCasing.txt (e.g., handling of Greek Final Sigma, > which is context-dependent instead of language-dependent but still one > of the Conditional Mappings) >=20 > 3. "Local case mapping" also does not apply to the Unconditional > Mappings from SpecialCasing.txt (which in general are mappings from > lowercase to titlecase and uppercase anyway, so we might not care = about > them) >=20 > If we look at the results in Appendix B.1 of = draft-ietf-precis-mappings > we see that they match the Language-Sensitive Mappings from the > SpecialCasing.txt file. So if that's all we're doing here, I wonder = why > Section 2.3 of our document needs to be so long -- why not just say > "apply the Language-Sensitive Mappings in SpecialCasing.txt" and be = done > with it? >=20 > Or, do we also need to also specify some of the context-dependent > mappings? (The major one is Greek final sigma.) As an example, in the > PRECIS nickname spec would uppercase "=CE=A6=CE=99=CE=9B=CE=9F=CE=A3 = =CE=9C=CE=9F=CE=99" ("my friend") be case > folded for comparison purposes to "=CF=86=CE=B9=CE=BB=CE=BF=CF=82 = =CE=BC=CE=BF=CE=B9" (with a Greek final sigma, > which is correct in Greek) or to "=CF=86=CE=B9=CE=BB=CE=BF=CF=83 = =CE=BC=CE=BF=CE=B9" (with a Greek medial sigma, > which is incorrect in Greek)? >=20 > And what about full case folding vs. simple case folding (e.g., =E1=BA=9E= =3D > U+1E9E to ss instead of =C3=9F =3D U+00DF)? Do we need to specify one = way to > handle characters where either full case folding or simple case = folding > can be applied, so that we have consistency for interop purposes? >=20 > Perhaps I'm missing something obvious, but IMHO at least Section 2.3 > needs to explain a bit more what we're trying to accomplish, and why. >=20 > Peter >=20 > --=20 > Peter Saint-Andre > https://stpeter.im/ >=20 >=20 > _______________________________________________ > precis mailing list > precis@ietf.org > https://www.ietf.org/mailman/listinfo/precis --Apple-Mail=_FBD5273B-B7E3-4A42-A7EF-3AED4E1FBA20 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
to the "Common Case Folding" that is mentioned in = the CaseFolding.txt file.

The targets of this = "Local Case Mapping" are the following characters which are = described
in the Language-Sensitive Mappings section in = the SpecialCasing.txt file.
(Language-Sensitive = Mappings are characters whose full case = mappings 
depend on language and perhaps = also context.)

For Turkish and = Azeri:
<Language>; <Codepoint>; = <Lowercase>; <Comments>
<Language> means the = alpha-2 codes in [ISO.3166-1].
tr; 0307; = ; COMBINING DOT ABOVE
tr; 0130; 0069; LATIN CAPITAL = LETTER I WITH DOT ABOVE
tr; 0049; 0131; LATIN CAPITAL LETTER = I
az; 0307; ; COMBINING DOT ABOVE
az; = 0130; 0069; LATIN CAPITAL LETTER I WITH DOT ABOVE
az; 0049; = 0131; LATIN CAPITAL LETTER = I

For Lithuanian is at the end of a = sentence.

In the CaseFolding.txt, it is written = that "Final Sigma" (as written bellow) Case-Folds 
to the = "Lowercase Sigma" as Common Case Folding. So let's say if the "Uppercase = Sigma" 
that comes at the end of a sentence is converted = to "Final Sigma" using Local Case Mapping, 
there is no = meaning. Because of this, I would not put Final Sigma as one of the = targets 
for Local Case Mapping = currently.

In CaseFolding.txt:
03C2; = C; 03C3; # GREEK SMALL LETTER FINAL = SIGMA

By the way, I investigated = Lithuanian which are described in SpecialCasing.txt file.
And = I found some problems. I would like to ask you = whether Lithuanian should be considered as a
target for = local case mapping as open issues.

In the = Lithuanian language, there are some characters that are unassigned in = the Unicode. 
For this reason, when a uppercase = characters with accent (as mentioned in = SpecialCasing.txt) 
is mapped into lowercase characters, = the characters of the Italian language are used = instead 
of the formal Lithuanian language = expression.

For example, the character =C3=AC; 00CC (i with a = grave accent) is being used in both the Lithuanian and Italian = language.
In Italian language, this lowercase character is expressed = as (=C3=AC; 00EC: Grave accent on dotless i), 
whereas = in Lithuanian language it is (i=CC=87=CC=80;  0069 0307 0300: = Grave accent on dotted i), differentiating both characters.
However, = in the input system of PC and smartphones that use the Lithuanian = language, 
Italian character  =C3=AC(00EC) = substitutes that role.

The difference of 00CC in CaseFolding.txt = and SpecialCasing.txt is as following:
CaseFolding.txt -> 00CC; C; = 00EC; # LATIN CAPITAL LETTER I WITH GRAVE
SpecialCasing.txt -> = 00CC; 0069 0307 0300; LATIN CAPITAL LETTER I WITH GRAVE

Looking = at the comparison between Lithuanian strings that contain 00CC and = 00EC, 
when they are local case mapped using the current = definition, 
and then followed by case mapping, they = become different strings.

So I'd like to hear your comment about = these.

I have two proposals for this problem. 
1)
In = the case of localized Lithuanian language, 00EC is mapped into = 0069;0307;0300 using local case mapping.

2)
In the future, as = there is be a possibility that the combined characters 0069;0307;0300 = into 1 character is registered in the Unicode, local case mapping = doesn't need to care about it.

Which proposal = is more preferable? Please let me know what you = think.

Regards,

Nemo

t.nemo10@kmd.keio.ac.jp
<= div>



On 2013/09/05, at 6:43, Peter Saint-Andre <stpeter@stpeter.im> = wrote:

As mentioned, I find Section 2.3 of = draft-ietf-precis-mappings hard to
understand. This message is a bit = long because I was puzzling over
things as I wrote it. I hope it's = not too rambling.

A relatively minor point: there's a bit of = confusion between
locale-dependent mapping and context-dependent = mapping. For instance:

  Local case mapping is case = folding that depends on language and
  context.  For = example, the mapping of LATIN CAPITAL LETTER I (U+0049)
=   depends on the language context of the user: if the language = is
  Turkish (or one of several other languages), the = character should be
  mapped into LATIN SMALL LETTER = DOTLESS I (U+0131) as this character's
  lower case = equivalent.

The first sentence is confusing because it says that = local case mapping
depends on language *and* context. I think we mean = language *or* context
(or, even better, locale or context, since the = Unicode standard talks
about "locale-dependent case mapping"). Also, = the use of "case folding"
might not be quite right here, because that = term has a very specific
meaning (e.g., Chapter 5.18 of the Unicode = standard says things like
"The Unicode case folding algorithm is = defined to be simpler and more
efficient than case mappings."). In = the next sentence, the phrase
"language context" will cause even more = confusion. :-) I think
"language" is enough here. Also I think it = would be helpful to add an
example of a context-dependent mapping = (but see below!).

Thus I suggest:

  Local case = mapping depends on locale or context.  As an example of
=   locale-dependent mapping, LATIN CAPITAL LETTER I (U+0049) = is
  normally mapped to LATIN SMALL LETTER I ((U+0069); = however, if the
  language is Turkish (or one of several = other languages), then the
  character should be mapped to = LATIN SMALL LETTER DOTLESS I (U+0131).
  As an example of = context-dependent mapping, GREEK CAPITAL LETTER
  SIGMA = (U+03A3) is mapped to GREEK SMALL LETTER SIGMA (U+03C3) if it
=   is followed by another letter, but is mapped to GREEK SMALL = LETTER
  FINAL SIGMA (U+03C2) if it is not followed by = another letter.

So that's the first paragraph. :-)

The = second paragraph says:

  Local case mapping targets = only characters that
  get two different results to = perform just casefolding that is defined
  in the = Casefolding.txt [Casefolding] and perform special casefolding
=   that is defined in the Specialcasing.txt then casefolding, = because
  PRECIS framework have casefolding.

(Nit: = The file names are actually CamelCase in the UCD, = i.e.,
CaseFolding.txt and SpecialCase.txt.)

That's a long = sentence. I suggest breaking it up (I started to do that
but then = bigger questions arose).

As I understand it "just casefolding" = isn't really defined in the
CaseFolding.txt file, because four kinds = of casefolding are specified
there: (1) common case folding, (2) full = case folding, (3) simple case
folding, and (4) Turkic mappings for = uppercase I and dotted uppercase I.

It's not clear to me exactly = what draft-ietf-precis-mappings is
recommending here. Is it saying = that local case mapping applies (a) when
there is a difference = between common case mapping and anything else, (b)
when there is no = common case folding, (c) when there are multiple
possible case = foldings, or (d) something else?

As examples:

1. Common = case folding handles things like LATIN CAPITAL LETTER A
(U+0041) to = LATIN SMALL LETTER A (U+0061). There are no alternative
mappings for = this character and it's handled by UnicodeData.txt.

2. Full case = folding can result in mapping to multiple characters, such
as LATIN = CAPITAL LETTER SHARP S (U+1E9E) to LATIN SMALL LETTER S
(U+0073) + = LATIN SMALL LETTER S (U+0073).

3. Simple case folding always maps = to a single character, such as LATIN
CAPITAL LETTER SHARP S (U+1E9E) = to LATIN SMALL LETTER SHARP S (U+00DF).

(As we see, there are = several possible case foldings for U+1E9E.)

4. LATIN CAPITAL = LETTER I commonly maps to LATIN SMALL LETTER I but
under Turkic = mappings it maps to LATIN SMALL LETTER DOTLESS I.

The = UnicodeData.txt file specifies one-to-one case mappings that = are
independent of language, locale, and context. Thus it doesn't = cover:

- full case folding (e.g., in UnicodeData.txt U+1E9E is = mapped to
U+00DF, not U+0073 U+073) since that's not = one-to-one

- context-specific mappings such as uppercase Greek = sigma to Greek final
sigma when followed by a space

- = locale-specific mappings such as LATIN CAPITAL LETTER I to LATIN = SMALL
LETTER DOTLESS I in Turkic languages

I think we need to = be clear about what we're trying to accomplish here.
Are we actually = addressing all mappings that are not handled by the
UnicodeData.txt = file (i.e., everything except "common case folding" as
specified by = the CaseFolding.txt file)? It seems that way to me (i.e.,
we need to = say something about context-specific mappings for sure, and
probably = also case folding that isn't one-to-one such as LATIN CAPITAL
SHARP S = to ss), but that's not what draft-ietf-precis-mappings says = now...

  There are two types casefoldings defined as = Unconditional Mappings
  and Conditional Mappings in the = Specialcasing.txt file.  Conditional
  mappings have = Language-Insensitive Mappings that target characters
=   whose full case mappings do not depend on language, but do = depend on
  context.  Language-Sensitive Mappings = that these are characters whose
  full case mappings = depend on language and perhaps also context.

  Of = these mappings, characters with Unconditional Mappings or with
=   Language-Insensitive Mappings in Conditional Mappings target = are
  mapped into same codepoint(s) with just casefolding = or special
  casefolding then casefolding.  But = characters with Language-Sensitive
  Mappings in = Conditional Mappings targets are mapped into different
=   codepoints.  Therefore this document defines characters = that are a
  part of characters of Lithuanian(lt), = Turkish(tr) and
  Azerbaijanian(az) that = Language-Sensitive Mappings targets as targets
  for local = case mapping.

As I read that text, it says:

1. "Local case = mapping" applies only to the Language-Sensitive Mappings
(one = division of the Conditional Mappings) from SpecialCasing.txt

2. = "Local case mapping" does not apply to the = Language-Insensitive
Mappings from SpecialCasing.txt (e.g., handling = of Greek Final Sigma,
which is context-dependent instead of = language-dependent but still one
of the Conditional = Mappings)

3. "Local case mapping" also does not apply to the = Unconditional
Mappings from SpecialCasing.txt (which in general are = mappings from
lowercase to titlecase and uppercase anyway, so we = might not care about
them)

If we look at the results in = Appendix B.1 of draft-ietf-precis-mappings
we see that they match the = Language-Sensitive Mappings from the
SpecialCasing.txt file. So if = that's all we're doing here, I wonder why
Section 2.3 of our document = needs to be so long -- why not just say
"apply the Language-Sensitive = Mappings in SpecialCasing.txt" and be done
with it?

Or, do we = also need to also specify some of the context-dependent
mappings? = (The major one is Greek final sigma.) As an example, in the
PRECIS = nickname spec would uppercase "=CE=A6=CE=99=CE=9B=CE=9F=CE=A3 =CE=9C=CE=9F= =CE=99" ("my friend") be case
folded for comparison purposes to = "=CF=86=CE=B9=CE=BB=CE=BF=CF=82 =CE=BC=CE=BF=CE=B9" (with a Greek final = sigma,
which is correct in Greek) or to "=CF=86=CE=B9=CE=BB=CE=BF=CF=83= =CE=BC=CE=BF=CE=B9" (with a Greek medial sigma,
which is incorrect = in Greek)?

And what about full case folding vs. simple case = folding (e.g., =E1=BA=9E =3D
U+1E9E to ss instead of =C3=9F =3D = U+00DF)? Do we need to specify one way to
handle characters where = either full case folding or simple case folding
can be applied, so = that we have consistency for interop purposes?

Perhaps I'm = missing something obvious, but IMHO at least Section 2.3
needs to = explain a bit more what we're trying to accomplish, and = why.

Peter

--
Peter Saint-Andre
https://stpeter.im/


__________= _____________________________________
precis mailing = list
precis@ietf.org
https://www.ietf.org/mailman/listinfo/precis

= --Apple-Mail=_FBD5273B-B7E3-4A42-A7EF-3AED4E1FBA20-- --Apple-Mail=_46A253EF-688E-4E44-BBB1-98915C01A95C 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 iQEcBAEBAgAGBQJSOCdMAAoJEJk7o/xhVanarOQIAMEh/+rx4vpcc1neAx2OtoG2 nIx+Xc11IrgnbWJDx0W3zv7Z5YKRZ6av7EqBU3zHay+1qBfm6druOIZFf2ZJ4I0q qOIYznEkRkgcvqOFpWWjrGpWBBTl4ducHvloj0fXgKHpLHs9FDkYKgyja3t0KyTF duO+wa6ZsBiM2VUna+NS3uCWcvlT2Eo3mGhD1uekLN83NB/nCPD7o8Et5voOzzZz WmKtxUHDSonQTOvYRguDMAXB/INUcPliQe5MlPOkzCKFTTkWHAU7S/xfw4P1LzuG /6wVFa3yQjSsdINgIEJFtW/cDsH4SK3rFY+1Zl8JkGsu4ozytMJ8lNCbAqKuyCY= =FZgE -----END PGP SIGNATURE----- --Apple-Mail=_46A253EF-688E-4E44-BBB1-98915C01A95C-- From t.nemo10@kmd.keio.ac.jp Thu Sep 19 00:39:43 2013 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 375A021F999D for ; Thu, 19 Sep 2013 00:39:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.853 X-Spam-Level: X-Spam-Status: No, score=0.853 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_50=0.001, FRT_BELOW2=2.154, GB_I_LETTER=-2, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q63iqiwmUYjT for ; Thu, 19 Sep 2013 00:39:25 -0700 (PDT) Received: from mail.kmd.keio.ac.jp (mail.kmd.keio.ac.jp [IPv6:2001:200:167:2e90::164]) by ietfa.amsl.com (Postfix) with ESMTP id 6F1D921F97C7 for ; Thu, 19 Sep 2013 00:39:24 -0700 (PDT) Received: from [IPv6:2001:200:167:2ec1:8509:1c53:c426:a04] (unknown [IPv6:2001:200:167:2ec1:8509:1c53:c426:a04]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.kmd.keio.ac.jp (Postfix) with ESMTPSA id 1D90B80412 for ; Thu, 19 Sep 2013 16:39:13 +0900 (JST) From: Takahiro Nemoto Content-Type: multipart/signed; boundary="Apple-Mail=_190EA3CE-EE00-4A4B-96BB-5F3A238BF09B"; protocol="application/pgp-signature"; micalg=pgp-sha1 Message-Id: <4C8248EF-51BD-4736-A930-E2FEE610EC03@kmd.keio.ac.jp> Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Date: Thu, 19 Sep 2013 16:39:12 +0900 References: <5227A979.7050403@stpeter.im> To: "precis@ietf.org" In-Reply-To: X-Mailer: Apple Mail (2.1508) Subject: Re: [precis] local case mapping X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 07:39:43 -0000 --Apple-Mail=_190EA3CE-EE00-4A4B-96BB-5F3A238BF09B Content-Type: multipart/alternative; boundary="Apple-Mail=_29F8FD84-C462-4690-B5B6-E532E92B993D" --Apple-Mail=_29F8FD84-C462-4690-B5B6-E532E92B993D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 My previous e-mail may be too long, so I tried to summarize it as = following; The purpose of local case mapping is to increase the probability=20 of matching-result from the comparison between uppercase and=20 lowercase characters, targeting language-dependent characters. In the current definition, current local case mapping targets the = characters=20 that give different results when the following is performed: 1. SpecialCasing and followed by Common CaseFolding 2. Common CaseFolding ONLY However, looking at the Lithuanian Use Case in which the character = =C3=AC(00EC)=20 of the Italian language is being used in place of the formal Lithuanian = lowercase=20 (but I am not an expert in Lithuanian language), it may not be = applicable in this case.=20 (It works without problem for other languages). So I have three proposals to handle this problem: 1. Leave it the way it is. 2. Exclude Lithuanian language from Local Case Mapping 3. Use a special table to handle Lithuanian language Considering the maintenance and preservation of the document,=20 leaving it the way it is now is not a bad idea. Regarding this Local = Case Mapping,=20 I would like to carry out a revision on I-D in this direction. I would appreciate your comment, if you have any. Regards, Nemo -- Takahiro Nemoto t.nemo10@kmd.keio.ac.jp On 2013/09/17, at 18:56, Takahiro Nemoto = wrote: > Hi, Peter-san and Alexey-san >=20 > Thank you for your thorough review and helpful comment. > Let me respond to the concerns that you raised in the previous email. >=20 > I'll try to simplify the mappings document that I wrote according to = your suggestion. >=20 > Local Case Mapping is targeted towards special characters that depends = on the language. > Also, the term "Case Folding" that I used in the mappings document = refers=20 > to the "Common Case Folding" that is mentioned in the CaseFolding.txt = file. >=20 > The targets of this "Local Case Mapping" are the following characters = which are described > in the Language-Sensitive Mappings section in the SpecialCasing.txt = file. > (Language-Sensitive Mappings are characters whose full case mappings=20= > depend on language and perhaps also context.) >=20 > For Turkish and Azeri: > ; ; ; > means the alpha-2 codes in [ISO.3166-1]. > tr; 0307; ; COMBINING DOT ABOVE > tr; 0130; 0069; LATIN CAPITAL LETTER I WITH DOT ABOVE > tr; 0049; 0131; LATIN CAPITAL LETTER I > az; 0307; ; COMBINING DOT ABOVE > az; 0130; 0069; LATIN CAPITAL LETTER I WITH DOT ABOVE > az; 0049; 0131; LATIN CAPITAL LETTER I >=20 > For Lithuanian is at the end of a sentence. >=20 > In the CaseFolding.txt, it is written that "Final Sigma" (as written = bellow) Case-Folds=20 > to the "Lowercase Sigma" as Common Case Folding. So let's say if the = "Uppercase Sigma"=20 > that comes at the end of a sentence is converted to "Final Sigma" = using Local Case Mapping,=20 > there is no meaning. Because of this, I would not put Final Sigma as = one of the targets=20 > for Local Case Mapping currently. >=20 > In CaseFolding.txt: > 03C2; C; 03C3; # GREEK SMALL LETTER FINAL SIGMA >=20 > By the way, I investigated Lithuanian which are described in = SpecialCasing.txt file. > And I found some problems. I would like to ask you whether Lithuanian = should be considered as a > target for local case mapping as open issues. >=20 > In the Lithuanian language, there are some characters that are = unassigned in the Unicode.=20 > For this reason, when a uppercase characters with accent (as mentioned = in SpecialCasing.txt)=20 > is mapped into lowercase characters, the characters of the Italian = language are used instead=20 > of the formal Lithuanian language expression. >=20 > For example, the character =C3=AC; 00CC (i with a grave accent) is = being used in both the Lithuanian and Italian language. > In Italian language, this lowercase character is expressed as (=C3=AC; = 00EC: Grave accent on dotless i),=20 > whereas in Lithuanian language it is (i=CC=87=CC=80; 0069 0307 0300: = Grave accent on dotted i), differentiating both characters. > However, in the input system of PC and smartphones that use the = Lithuanian language,=20 > Italian character =C3=AC(00EC) substitutes that role. >=20 > The difference of 00CC in CaseFolding.txt and SpecialCasing.txt is as = following: > CaseFolding.txt -> 00CC; C; 00EC; # LATIN CAPITAL LETTER I WITH GRAVE > SpecialCasing.txt -> 00CC; 0069 0307 0300; LATIN CAPITAL LETTER I WITH = GRAVE >=20 > Looking at the comparison between Lithuanian strings that contain 00CC = and 00EC,=20 > when they are local case mapped using the current definition,=20 > and then followed by case mapping, they become different strings. >=20 > So I'd like to hear your comment about these. >=20 > I have two proposals for this problem.=20 > 1) > In the case of localized Lithuanian language, 00EC is mapped into = 0069;0307;0300 using local case mapping. >=20 > 2) > In the future, as there is be a possibility that the combined = characters 0069;0307;0300 into 1 character is registered in the Unicode, = local case mapping doesn't need to care about it. >=20 > Which proposal is more preferable? Please let me know what you think. >=20 > Regards, >=20 > Nemo >=20 > -- > Takahiro Nemoto > t.nemo10@kmd.keio.ac.jp >=20 >=20 >=20 >=20 > On 2013/09/05, at 6:43, Peter Saint-Andre wrote: >=20 >> As mentioned, I find Section 2.3 of draft-ietf-precis-mappings hard = to >> understand. This message is a bit long because I was puzzling over >> things as I wrote it. I hope it's not too rambling. >>=20 >> A relatively minor point: there's a bit of confusion between >> locale-dependent mapping and context-dependent mapping. For instance: >>=20 >> Local case mapping is case folding that depends on language and >> context. For example, the mapping of LATIN CAPITAL LETTER I = (U+0049) >> depends on the language context of the user: if the language is >> Turkish (or one of several other languages), the character should = be >> mapped into LATIN SMALL LETTER DOTLESS I (U+0131) as this = character's >> lower case equivalent. >>=20 >> The first sentence is confusing because it says that local case = mapping >> depends on language *and* context. I think we mean language *or* = context >> (or, even better, locale or context, since the Unicode standard talks >> about "locale-dependent case mapping"). Also, the use of "case = folding" >> might not be quite right here, because that term has a very specific >> meaning (e.g., Chapter 5.18 of the Unicode standard says things like >> "The Unicode case folding algorithm is defined to be simpler and more >> efficient than case mappings."). In the next sentence, the phrase >> "language context" will cause even more confusion. :-) I think >> "language" is enough here. Also I think it would be helpful to add an >> example of a context-dependent mapping (but see below!). >>=20 >> Thus I suggest: >>=20 >> Local case mapping depends on locale or context. As an example of >> locale-dependent mapping, LATIN CAPITAL LETTER I (U+0049) is >> normally mapped to LATIN SMALL LETTER I ((U+0069); however, if the >> language is Turkish (or one of several other languages), then the >> character should be mapped to LATIN SMALL LETTER DOTLESS I = (U+0131). >> As an example of context-dependent mapping, GREEK CAPITAL LETTER >> SIGMA (U+03A3) is mapped to GREEK SMALL LETTER SIGMA (U+03C3) if it >> is followed by another letter, but is mapped to GREEK SMALL LETTER >> FINAL SIGMA (U+03C2) if it is not followed by another letter. >>=20 >> So that's the first paragraph. :-) >>=20 >> The second paragraph says: >>=20 >> Local case mapping targets only characters that >> get two different results to perform just casefolding that is = defined >> in the Casefolding.txt [Casefolding] and perform special = casefolding >> that is defined in the Specialcasing.txt then casefolding, because >> PRECIS framework have casefolding. >>=20 >> (Nit: The file names are actually CamelCase in the UCD, i.e., >> CaseFolding.txt and SpecialCase.txt.) >>=20 >> That's a long sentence. I suggest breaking it up (I started to do = that >> but then bigger questions arose). >>=20 >> As I understand it "just casefolding" isn't really defined in the >> CaseFolding.txt file, because four kinds of casefolding are specified >> there: (1) common case folding, (2) full case folding, (3) simple = case >> folding, and (4) Turkic mappings for uppercase I and dotted uppercase = I. >>=20 >> It's not clear to me exactly what draft-ietf-precis-mappings is >> recommending here. Is it saying that local case mapping applies (a) = when >> there is a difference between common case mapping and anything else, = (b) >> when there is no common case folding, (c) when there are multiple >> possible case foldings, or (d) something else? >>=20 >> As examples: >>=20 >> 1. Common case folding handles things like LATIN CAPITAL LETTER A >> (U+0041) to LATIN SMALL LETTER A (U+0061). There are no alternative >> mappings for this character and it's handled by UnicodeData.txt. >>=20 >> 2. Full case folding can result in mapping to multiple characters, = such >> as LATIN CAPITAL LETTER SHARP S (U+1E9E) to LATIN SMALL LETTER S >> (U+0073) + LATIN SMALL LETTER S (U+0073). >>=20 >> 3. Simple case folding always maps to a single character, such as = LATIN >> CAPITAL LETTER SHARP S (U+1E9E) to LATIN SMALL LETTER SHARP S = (U+00DF). >>=20 >> (As we see, there are several possible case foldings for U+1E9E.) >>=20 >> 4. LATIN CAPITAL LETTER I commonly maps to LATIN SMALL LETTER I but >> under Turkic mappings it maps to LATIN SMALL LETTER DOTLESS I. >>=20 >> The UnicodeData.txt file specifies one-to-one case mappings that are >> independent of language, locale, and context. Thus it doesn't cover: >>=20 >> - full case folding (e.g., in UnicodeData.txt U+1E9E is mapped to >> U+00DF, not U+0073 U+073) since that's not one-to-one >>=20 >> - context-specific mappings such as uppercase Greek sigma to Greek = final >> sigma when followed by a space >>=20 >> - locale-specific mappings such as LATIN CAPITAL LETTER I to LATIN = SMALL >> LETTER DOTLESS I in Turkic languages >>=20 >> I think we need to be clear about what we're trying to accomplish = here. >> Are we actually addressing all mappings that are not handled by the >> UnicodeData.txt file (i.e., everything except "common case folding" = as >> specified by the CaseFolding.txt file)? It seems that way to me = (i.e., >> we need to say something about context-specific mappings for sure, = and >> probably also case folding that isn't one-to-one such as LATIN = CAPITAL >> SHARP S to ss), but that's not what draft-ietf-precis-mappings says = now... >>=20 >> There are two types casefoldings defined as Unconditional Mappings >> and Conditional Mappings in the Specialcasing.txt file. = Conditional >> mappings have Language-Insensitive Mappings that target characters >> whose full case mappings do not depend on language, but do depend = on >> context. Language-Sensitive Mappings that these are characters = whose >> full case mappings depend on language and perhaps also context. >>=20 >> Of these mappings, characters with Unconditional Mappings or with >> Language-Insensitive Mappings in Conditional Mappings target are >> mapped into same codepoint(s) with just casefolding or special >> casefolding then casefolding. But characters with = Language-Sensitive >> Mappings in Conditional Mappings targets are mapped into different >> codepoints. Therefore this document defines characters that are a >> part of characters of Lithuanian(lt), Turkish(tr) and >> Azerbaijanian(az) that Language-Sensitive Mappings targets as = targets >> for local case mapping. >>=20 >> As I read that text, it says: >>=20 >> 1. "Local case mapping" applies only to the Language-Sensitive = Mappings >> (one division of the Conditional Mappings) from SpecialCasing.txt >>=20 >> 2. "Local case mapping" does not apply to the Language-Insensitive >> Mappings from SpecialCasing.txt (e.g., handling of Greek Final Sigma, >> which is context-dependent instead of language-dependent but still = one >> of the Conditional Mappings) >>=20 >> 3. "Local case mapping" also does not apply to the Unconditional >> Mappings from SpecialCasing.txt (which in general are mappings from >> lowercase to titlecase and uppercase anyway, so we might not care = about >> them) >>=20 >> If we look at the results in Appendix B.1 of = draft-ietf-precis-mappings >> we see that they match the Language-Sensitive Mappings from the >> SpecialCasing.txt file. So if that's all we're doing here, I wonder = why >> Section 2.3 of our document needs to be so long -- why not just say >> "apply the Language-Sensitive Mappings in SpecialCasing.txt" and be = done >> with it? >>=20 >> Or, do we also need to also specify some of the context-dependent >> mappings? (The major one is Greek final sigma.) As an example, in the >> PRECIS nickname spec would uppercase "=CE=A6=CE=99=CE=9B=CE=9F=CE=A3 = =CE=9C=CE=9F=CE=99" ("my friend") be case >> folded for comparison purposes to "=CF=86=CE=B9=CE=BB=CE=BF=CF=82 = =CE=BC=CE=BF=CE=B9" (with a Greek final sigma, >> which is correct in Greek) or to "=CF=86=CE=B9=CE=BB=CE=BF=CF=83 = =CE=BC=CE=BF=CE=B9" (with a Greek medial sigma, >> which is incorrect in Greek)? >>=20 >> And what about full case folding vs. simple case folding (e.g., =E1=BA=9E= =3D >> U+1E9E to ss instead of =C3=9F =3D U+00DF)? Do we need to specify one = way to >> handle characters where either full case folding or simple case = folding >> can be applied, so that we have consistency for interop purposes? >>=20 >> Perhaps I'm missing something obvious, but IMHO at least Section 2.3 >> needs to explain a bit more what we're trying to accomplish, and why. >>=20 >> Peter >>=20 >> --=20 >> Peter Saint-Andre >> https://stpeter.im/ >>=20 >>=20 >> _______________________________________________ >> precis mailing list >> precis@ietf.org >> https://www.ietf.org/mailman/listinfo/precis >=20 > _______________________________________________ > precis mailing list > precis@ietf.org > https://www.ietf.org/mailman/listinfo/precis --Apple-Mail=_29F8FD84-C462-4690-B5B6-E532E92B993D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
t.nemo10@kmd.keio.ac.jp
<= div>



On 2013/09/17, at 18:56, Takahiro Nemoto <t.nemo10@kmd.keio.ac.jp> = wrote:

Hi, Peter-san and = Alexey-san

Thank you for your = thorough review and helpful comment.
Let me = respond to the concerns that you raised in the previous = email.

I'll try to simplify the mappings = document that I wrote according to your = suggestion.

Local Case Mapping is targeted = towards special characters that depends on the language.
Also, = the term "Case Folding" that I used in the mappings document = refers 
to the "Common Case Folding" that is mentioned in = the CaseFolding.txt file.

The targets of this = "Local Case Mapping" are the following characters which are = described
in the Language-Sensitive Mappings section in = the SpecialCasing.txt file.
(Language-Sensitive = Mappings are characters whose full case = mappings 
depend on language and perhaps = also context.)

For Turkish and = Azeri:
<Language>; <Codepoint>; = <Lowercase>; <Comments>
<Language> means the = alpha-2 codes in [ISO.3166-1].
tr; 0307; = ; COMBINING DOT ABOVE
tr; 0130; 0069; LATIN CAPITAL = LETTER I WITH DOT ABOVE
tr; 0049; 0131; LATIN CAPITAL LETTER = I
az; 0307; ; COMBINING DOT ABOVE
az; = 0130; 0069; LATIN CAPITAL LETTER I WITH DOT ABOVE
az; 0049; = 0131; LATIN CAPITAL LETTER = I

For Lithuanian is at the end of a = sentence.

In the CaseFolding.txt, it is written = that "Final Sigma" (as written bellow) Case-Folds 
to the = "Lowercase Sigma" as Common Case Folding. So let's say if the "Uppercase = Sigma" 
that comes at the end of a sentence is converted = to "Final Sigma" using Local Case Mapping, 
there is no = meaning. Because of this, I would not put Final Sigma as one of the = targets 
for Local Case Mapping = currently.

In CaseFolding.txt:
03C2; = C; 03C3; # GREEK SMALL LETTER FINAL = SIGMA

By the way, I investigated = Lithuanian which are described in SpecialCasing.txt file.
And = I found some problems. I would like to ask you = whether Lithuanian should be considered as a
target for = local case mapping as open issues.

In the = Lithuanian language, there are some characters that are unassigned in = the Unicode. 
For this reason, when a uppercase = characters with accent (as mentioned in = SpecialCasing.txt) 
is mapped into lowercase characters, = the characters of the Italian language are used = instead 
of the formal Lithuanian language = expression.

For example, the character =C3=AC; 00CC (i with a = grave accent) is being used in both the Lithuanian and Italian = language.
In Italian language, this lowercase character is expressed = as (=C3=AC; 00EC: Grave accent on dotless i), 
whereas = in Lithuanian language it is (i=CC=87=CC=80;  0069 0307 0300: = Grave accent on dotted i), differentiating both characters.
However, = in the input system of PC and smartphones that use the Lithuanian = language, 
Italian character  =C3=AC(00EC) = substitutes that role.

The difference of 00CC in CaseFolding.txt = and SpecialCasing.txt is as following:
CaseFolding.txt -> 00CC; C; = 00EC; # LATIN CAPITAL LETTER I WITH GRAVE
SpecialCasing.txt -> = 00CC; 0069 0307 0300; LATIN CAPITAL LETTER I WITH GRAVE

Looking = at the comparison between Lithuanian strings that contain 00CC and = 00EC, 
when they are local case mapped using the current = definition, 
and then followed by case mapping, they = become different strings.

So I'd like to hear your comment about = these.

I have two proposals for this problem. 
1)
In = the case of localized Lithuanian language, 00EC is mapped into = 0069;0307;0300 using local case mapping.

2)
In the future, as = there is be a possibility that the combined characters 0069;0307;0300 = into 1 character is registered in the Unicode, local case mapping = doesn't need to care about it.

Which proposal = is more preferable? Please let me know what you = think.

Regards,

Nemo

t.nemo10@kmd.keio.ac.jp
<= div>



On 2013/09/05, at 6:43, Peter Saint-Andre <stpeter@stpeter.im> = wrote:

As mentioned, I find Section 2.3 of = draft-ietf-precis-mappings hard to
understand. This message is a bit = long because I was puzzling over
things as I wrote it. I hope it's = not too rambling.

A relatively minor point: there's a bit of = confusion between
locale-dependent mapping and context-dependent = mapping. For instance:

  Local case mapping is case = folding that depends on language and
  context.  For = example, the mapping of LATIN CAPITAL LETTER I (U+0049)
=   depends on the language context of the user: if the language = is
  Turkish (or one of several other languages), the = character should be
  mapped into LATIN SMALL LETTER = DOTLESS I (U+0131) as this character's
  lower case = equivalent.

The first sentence is confusing because it says that = local case mapping
depends on language *and* context. I think we mean = language *or* context
(or, even better, locale or context, since the = Unicode standard talks
about "locale-dependent case mapping"). Also, = the use of "case folding"
might not be quite right here, because that = term has a very specific
meaning (e.g., Chapter 5.18 of the Unicode = standard says things like
"The Unicode case folding algorithm is = defined to be simpler and more
efficient than case mappings."). In = the next sentence, the phrase
"language context" will cause even more = confusion. :-) I think
"language" is enough here. Also I think it = would be helpful to add an
example of a context-dependent mapping = (but see below!).

Thus I suggest:

  Local case = mapping depends on locale or context.  As an example of
=   locale-dependent mapping, LATIN CAPITAL LETTER I (U+0049) = is
  normally mapped to LATIN SMALL LETTER I ((U+0069); = however, if the
  language is Turkish (or one of several = other languages), then the
  character should be mapped to = LATIN SMALL LETTER DOTLESS I (U+0131).
  As an example of = context-dependent mapping, GREEK CAPITAL LETTER
  SIGMA = (U+03A3) is mapped to GREEK SMALL LETTER SIGMA (U+03C3) if it
=   is followed by another letter, but is mapped to GREEK SMALL = LETTER
  FINAL SIGMA (U+03C2) if it is not followed by = another letter.

So that's the first paragraph. :-)

The = second paragraph says:

  Local case mapping targets = only characters that
  get two different results to = perform just casefolding that is defined
  in the = Casefolding.txt [Casefolding] and perform special casefolding
=   that is defined in the Specialcasing.txt then casefolding, = because
  PRECIS framework have casefolding.

(Nit: = The file names are actually CamelCase in the UCD, = i.e.,
CaseFolding.txt and SpecialCase.txt.)

That's a long = sentence. I suggest breaking it up (I started to do that
but then = bigger questions arose).

As I understand it "just casefolding" = isn't really defined in the
CaseFolding.txt file, because four kinds = of casefolding are specified
there: (1) common case folding, (2) full = case folding, (3) simple case
folding, and (4) Turkic mappings for = uppercase I and dotted uppercase I.

It's not clear to me exactly = what draft-ietf-precis-mappings is
recommending here. Is it saying = that local case mapping applies (a) when
there is a difference = between common case mapping and anything else, (b)
when there is no = common case folding, (c) when there are multiple
possible case = foldings, or (d) something else?

As examples:

1. Common = case folding handles things like LATIN CAPITAL LETTER A
(U+0041) to = LATIN SMALL LETTER A (U+0061). There are no alternative
mappings for = this character and it's handled by UnicodeData.txt.

2. Full case = folding can result in mapping to multiple characters, such
as LATIN = CAPITAL LETTER SHARP S (U+1E9E) to LATIN SMALL LETTER S
(U+0073) + = LATIN SMALL LETTER S (U+0073).

3. Simple case folding always maps = to a single character, such as LATIN
CAPITAL LETTER SHARP S (U+1E9E) = to LATIN SMALL LETTER SHARP S (U+00DF).

(As we see, there are = several possible case foldings for U+1E9E.)

4. LATIN CAPITAL = LETTER I commonly maps to LATIN SMALL LETTER I but
under Turkic = mappings it maps to LATIN SMALL LETTER DOTLESS I.

The = UnicodeData.txt file specifies one-to-one case mappings that = are
independent of language, locale, and context. Thus it doesn't = cover:

- full case folding (e.g., in UnicodeData.txt U+1E9E is = mapped to
U+00DF, not U+0073 U+073) since that's not = one-to-one

- context-specific mappings such as uppercase Greek = sigma to Greek final
sigma when followed by a space

- = locale-specific mappings such as LATIN CAPITAL LETTER I to LATIN = SMALL
LETTER DOTLESS I in Turkic languages

I think we need to = be clear about what we're trying to accomplish here.
Are we actually = addressing all mappings that are not handled by the
UnicodeData.txt = file (i.e., everything except "common case folding" as
specified by = the CaseFolding.txt file)? It seems that way to me (i.e.,
we need to = say something about context-specific mappings for sure, and
probably = also case folding that isn't one-to-one such as LATIN CAPITAL
SHARP S = to ss), but that's not what draft-ietf-precis-mappings says = now...

  There are two types casefoldings defined as = Unconditional Mappings
  and Conditional Mappings in the = Specialcasing.txt file.  Conditional
  mappings have = Language-Insensitive Mappings that target characters
=   whose full case mappings do not depend on language, but do = depend on
  context.  Language-Sensitive Mappings = that these are characters whose
  full case mappings = depend on language and perhaps also context.

  Of = these mappings, characters with Unconditional Mappings or with
=   Language-Insensitive Mappings in Conditional Mappings target = are
  mapped into same codepoint(s) with just casefolding = or special
  casefolding then casefolding.  But = characters with Language-Sensitive
  Mappings in = Conditional Mappings targets are mapped into different
=   codepoints.  Therefore this document defines characters = that are a
  part of characters of Lithuanian(lt), = Turkish(tr) and
  Azerbaijanian(az) that = Language-Sensitive Mappings targets as targets
  for local = case mapping.

As I read that text, it says:

1. "Local case = mapping" applies only to the Language-Sensitive Mappings
(one = division of the Conditional Mappings) from SpecialCasing.txt

2. = "Local case mapping" does not apply to the = Language-Insensitive
Mappings from SpecialCasing.txt (e.g., handling = of Greek Final Sigma,
which is context-dependent instead of = language-dependent but still one
of the Conditional = Mappings)

3. "Local case mapping" also does not apply to the = Unconditional
Mappings from SpecialCasing.txt (which in general are = mappings from
lowercase to titlecase and uppercase anyway, so we = might not care about
them)

If we look at the results in = Appendix B.1 of draft-ietf-precis-mappings
we see that they match the = Language-Sensitive Mappings from the
SpecialCasing.txt file. So if = that's all we're doing here, I wonder why
Section 2.3 of our document = needs to be so long -- why not just say
"apply the Language-Sensitive = Mappings in SpecialCasing.txt" and be done
with it?

Or, do we = also need to also specify some of the context-dependent
mappings? = (The major one is Greek final sigma.) As an example, in the
PRECIS = nickname spec would uppercase "=CE=A6=CE=99=CE=9B=CE=9F=CE=A3 =CE=9C=CE=9F= =CE=99" ("my friend") be case
folded for comparison purposes to = "=CF=86=CE=B9=CE=BB=CE=BF=CF=82 =CE=BC=CE=BF=CE=B9" (with a Greek final = sigma,
which is correct in Greek) or to "=CF=86=CE=B9=CE=BB=CE=BF=CF=83= =CE=BC=CE=BF=CE=B9" (with a Greek medial sigma,
which is incorrect = in Greek)?

And what about full case folding vs. simple case = folding (e.g., =E1=BA=9E =3D
U+1E9E to ss instead of =C3=9F =3D = U+00DF)? Do we need to specify one way to
handle characters where = either full case folding or simple case folding
can be applied, so = that we have consistency for interop purposes?

Perhaps I'm = missing something obvious, but IMHO at least Section 2.3
needs to = explain a bit more what we're trying to accomplish, and = why.

Peter

--
Peter Saint-Andre
https://stpeter.im/


__________= _____________________________________
precis mailing list
precis@ietf.org
https://www.ietf.or= g/mailman/listinfo/precis

________________= _______________________________
precis mailing list
precis@ietf.org
https://www.ietf.or= g/mailman/listinfo/precis

= --Apple-Mail=_29F8FD84-C462-4690-B5B6-E532E92B993D-- --Apple-Mail=_190EA3CE-EE00-4A4B-96BB-5F3A238BF09B 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 iQEcBAEBAgAGBQJSOqogAAoJEJk7o/xhVanarfAH/3fL8EJTnucB+gmKn6oc2ck9 3prRC+wdwzHTrqu4Jad1mrGxwwC7A98hOZQVxo3fFmrhEPoQRTIpvQE+zfiJTFjG e8iUIovazzV5h4/bIv2Qi2tst2uZJUk7I+p2KgLXFS9OsMKtATj/fF8hJVnVAPQi TBctqhKwWfZBg1u+Zq0FCPvixXsv8OVBDMyY+B+UR48hc+tbi2EzGKMVvYol0JBf sg5nN9C+AlRlLd1NQY7qiLqZ3rwUZ8CnkrPj7gJCYO9P3YJFhgiSR18tzHWYowU+ SNfWAVjF8pKjwwwIUys8xdbyXYhpSZx1umpXYScOroFQx5cH42p/PhNYtEe/TXE= =1C2E -----END PGP SIGNATURE----- --Apple-Mail=_190EA3CE-EE00-4A4B-96BB-5F3A238BF09B-- From simon@josefsson.org Tue Sep 24 03:01:11 2013 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 CF1D321F9C10; Tue, 24 Sep 2013 03:01:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nkrx5+VI9aBb; Tue, 24 Sep 2013 03:01:11 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) by ietfa.amsl.com (Postfix) with ESMTP id 1116E21F9BF7; Tue, 24 Sep 2013 03:01:10 -0700 (PDT) Received: from latte.josefsson.org (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id r8OA139F030639 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 24 Sep 2013 12:01:05 +0200 From: Simon Josefsson To: Florian Zeitz References: <51FEEC99.1020901@stpeter.im> <52090F96.30700@stpeter.im> <522E5CAA.5010902@stpeter.im> <5230B3B3.3040805@babelmonkeys.de> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:130924:florob@babelmonkeys.de::SYRXApsEcBUb3N0E:3nZ9 X-Hashcash: 1:22:130924:kitten@ietf.org::7iioqIQBWzIOcn3q:9qc6 X-Hashcash: 1:22:130924:precis@ietf.org::XUr0nA53F4DBSNJp:DuDm Date: Tue, 24 Sep 2013 12:01:03 +0200 In-Reply-To: <5230B3B3.3040805@babelmonkeys.de> (Florian Zeitz's message of "Wed, 11 Sep 2013 20:17:23 +0200") Message-ID: <87zjr2pmhs.fsf@latte.josefsson.org> User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97.8 at duva.sjd.se X-Virus-Status: Clean Cc: "kitten@ietf.org" , "precis@ietf.org" Subject: Re: [precis] [kitten] Fwd: Re: I-D Action: draft-ietf-precis-saslprepbis-04.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 10:01:11 -0000 Florian Zeitz writes: > While online games might not always want case folded strings, I doubt > having two usernames that differ only in case is ever desirable. I have accounts in systems were that is used -- for example, in one I have a lower-case username 'jas' for the ordinary user and an uppercase variant 'JAS' as a personalized admin account. In general, I believe that any I18N solution that disallow reasonable semantics of how username and passwords are interpreted will be completely ignored. What can (and should) be discussed is what "reasonable semantics" means. But forcing uppercase and lowercase characters to be regarded as the same is to me so completely and obviously unreasonable that I believe there is a disconnect between requirements and solution. /Simon From hartmans@mit.edu Tue Sep 24 07:18:11 2013 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 238C111E8133; Tue, 24 Sep 2013 07:18:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YOUxPfuHk3OM; Tue, 24 Sep 2013 07:18:06 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id D6FB911E8129; Tue, 24 Sep 2013 07:18:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 28C5A2043C; Tue, 24 Sep 2013 10:17:10 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VLpvcj8X3ugU; Tue, 24 Sep 2013 10:17:09 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Tue, 24 Sep 2013 10:17:09 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id E240287FE8; Tue, 24 Sep 2013 10:17:57 -0400 (EDT) From: Sam Hartman To: Simon Josefsson References: <51FEEC99.1020901@stpeter.im> <52090F96.30700@stpeter.im> <522E5CAA.5010902@stpeter.im> <5230B3B3.3040805@babelmonkeys.de> <87zjr2pmhs.fsf@latte.josefsson.org> Date: Tue, 24 Sep 2013 10:17:57 -0400 In-Reply-To: <87zjr2pmhs.fsf@latte.josefsson.org> (Simon Josefsson's message of "Tue, 24 Sep 2013 12:01:03 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Tue, 24 Sep 2013 07:30:19 -0700 Cc: "kitten@ietf.org" , "precis@ietf.org" Subject: Re: [precis] [kitten] Fwd: Re: I-D Action: draft-ietf-precis-saslprepbis-04.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 14:18:11 -0000 >>>>> "Simon" == Simon Josefsson writes: Simon> Florian Zeitz writes: >> While online games might not always want case folded strings, I >> doubt having two usernames that differ only in case is ever >> desirable. Simon> I have accounts in systems were that is used -- for example, Simon> in one I have a lower-case username 'jas' for the ordinary Simon> user and an uppercase variant 'JAS' as a personalized admin Simon> account. Simon> In general, I believe that any I18N solution that disallow Simon> reasonable semantics of how username and passwords are Simon> interpreted will be completely ignored. What can (and Simon> should) be discussed is what "reasonable semantics" means. Simon> But forcing uppercase and lowercase characters to be regarded Simon> as the same is to me so completely and obviously unreasonable Simon> that I believe there is a disconnect between requirements and Simon> solution. For myself, I've viewed a lot of systems, some of which case fold usernames and some of which do not. I think there's a lot of evidence that systems like AD that case-fold usernames are easier to use. In my mind sufficient evidence to try and move the internet in that direction. From simon@josefsson.org Tue Sep 24 13:27:06 2013 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 3FC3611E8165; Tue, 24 Sep 2013 13:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PvP7ITMDBZso; Tue, 24 Sep 2013 13:27:05 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) by ietfa.amsl.com (Postfix) with ESMTP id 4C53721F90DC; Tue, 24 Sep 2013 13:27:04 -0700 (PDT) Received: from latte.josefsson.org (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id r8OKR1Gf013683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 24 Sep 2013 22:27:02 +0200 From: Simon Josefsson To: Sam Hartman References: <51FEEC99.1020901@stpeter.im> <52090F96.30700@stpeter.im> <522E5CAA.5010902@stpeter.im> <5230B3B3.3040805@babelmonkeys.de> <87zjr2pmhs.fsf@latte.josefsson.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:130924:precis@ietf.org::HTGEColy34iEnELB:2CP9 X-Hashcash: 1:22:130924:kitten@ietf.org::UxBACrsq0/BbRMxp:BGB0 X-Hashcash: 1:22:130924:hartmans-ietf@mit.edu::1f8Q4UrPaDZAEnml:6uA7 Date: Tue, 24 Sep 2013 22:27:01 +0200 In-Reply-To: (Sam Hartman's message of "Tue, 24 Sep 2013 10:17:57 -0400") Message-ID: <87txharmne.fsf@latte.josefsson.org> User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97.8 at duva.sjd.se X-Virus-Status: Clean Cc: "kitten@ietf.org" , "precis@ietf.org" Subject: Re: [precis] [kitten] Fwd: Re: I-D Action: draft-ietf-precis-saslprepbis-04.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 20:27:06 -0000 Sam Hartman writes: >>>>>> "Simon" == Simon Josefsson writes: > > Simon> Florian Zeitz writes: > >> While online games might not always want case folded strings, I > >> doubt having two usernames that differ only in case is ever > >> desirable. > > Simon> I have accounts in systems were that is used -- for example, > Simon> in one I have a lower-case username 'jas' for the ordinary > Simon> user and an uppercase variant 'JAS' as a personalized admin > Simon> account. > > Simon> In general, I believe that any I18N solution that disallow > Simon> reasonable semantics of how username and passwords are > Simon> interpreted will be completely ignored. What can (and > Simon> should) be discussed is what "reasonable semantics" means. > Simon> But forcing uppercase and lowercase characters to be regarded > Simon> as the same is to me so completely and obviously unreasonable > Simon> that I believe there is a disconnect between requirements and > Simon> solution. > > For myself, I've viewed a lot of systems, some of which case fold > usernames and some of which do not. > > I think there's a lot of evidence that systems like AD that case-fold > usernames are easier to use. > In my mind sufficient evidence to try and move the internet in that > direction. I disagree that an I18N document is the appropriate way to move the Internet to case-insensitive usernames. If case-sensitive usernames is a significant problem, then it should be possible to publish a BCP recommending against that. Then existing protocols with case-sensitive usernames like HTTP, FTP, SMTP, SSH, etc could be revised. I don't believe any of that will happen, so we'll have to live with case sensitive usernames, and my take is that I18N documents should permit that. /Simon From hartmans@mit.edu Tue Sep 24 13:44:29 2013 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 BB7AA11E8167; Tue, 24 Sep 2013 13:44:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PlKwHaFEJvpA; Tue, 24 Sep 2013 13:44:24 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 08E0811E8165; Tue, 24 Sep 2013 13:44:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 78C482043F; Tue, 24 Sep 2013 16:43:15 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EowDG324SRh1; Tue, 24 Sep 2013 16:43:14 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Tue, 24 Sep 2013 16:43:14 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 9480687FE8; Tue, 24 Sep 2013 16:44:03 -0400 (EDT) From: Sam Hartman To: Simon Josefsson References: <51FEEC99.1020901@stpeter.im> <52090F96.30700@stpeter.im> <522E5CAA.5010902@stpeter.im> <5230B3B3.3040805@babelmonkeys.de> <87zjr2pmhs.fsf@latte.josefsson.org> <87txharmne.fsf@latte.josefsson.org> Date: Tue, 24 Sep 2013 16:44:03 -0400 In-Reply-To: <87txharmne.fsf@latte.josefsson.org> (Simon Josefsson's message of "Tue, 24 Sep 2013 22:27:01 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "kitten@ietf.org" , Sam Hartman , "precis@ietf.org" Subject: Re: [precis] [kitten] Fwd: Re: I-D Action: draft-ietf-precis-saslprepbis-04.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 20:44:29 -0000 >>>>> "Simon" == Simon Josefsson writes: Simon> like HTTP, FTP, SMTP, SSH, etc could be revised. I don't Simon> believe any of that will happen, so we'll have to live with Simon> case sensitive usernames, and my take is that I18N documents Simon> should permit that. I'm not sure any of the above hase case sensitive usernames. They permit usernames to be case sensitive. However a lot of implementations treat the username as case insensitive. I do think this is an appropriate issue for an IETF an document, but I do think considering the impact on legacy systems is important. I don't think we need to require there be no impact, simply understand an accept it. From simon@josefsson.org Tue Sep 24 14:17:54 2013 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 E71EA21F9CDA; Tue, 24 Sep 2013 14:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zuurd2Aol3L2; Tue, 24 Sep 2013 14:17:54 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) by ietfa.amsl.com (Postfix) with ESMTP id 13AA221F9CDF; Tue, 24 Sep 2013 14:17:51 -0700 (PDT) Received: from latte.josefsson.org (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id r8OLHnwt022918 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 24 Sep 2013 23:17:50 +0200 Date: Tue, 24 Sep 2013 23:17:46 +0200 From: Simon Josefsson To: Sam Hartman Message-ID: <20130924231746.73c578b7@latte.josefsson.org> In-Reply-To: References: <51FEEC99.1020901@stpeter.im> <52090F96.30700@stpeter.im> <522E5CAA.5010902@stpeter.im> <5230B3B3.3040805@babelmonkeys.de> <87zjr2pmhs.fsf@latte.josefsson.org> <87txharmne.fsf@latte.josefsson.org> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.10; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.8 at duva.sjd.se X-Virus-Status: Clean Cc: "kitten@ietf.org" , "precis@ietf.org" Subject: Re: [precis] [kitten] Fwd: Re: I-D Action: draft-ietf-precis-saslprepbis-04.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 21:17:55 -0000 You wrote: > >>>>> "Simon" == Simon Josefsson writes: > > Simon> like HTTP, FTP, SMTP, SSH, etc could be revised. I don't > Simon> believe any of that will happen, so we'll have to live with > Simon> case sensitive usernames, and my take is that I18N > Simon> documents should permit that. > > I'm not sure any of the above hase case sensitive usernames. > They permit usernames to be case sensitive. > However a lot of implementations treat the username as case > insensitive. > > I do think this is an appropriate issue for an IETF an document, but I > do think considering the impact on legacy systems is important. > I don't think we need to require there be no impact, simply understand > an accept it. Agreed, but the devil is in the detail. For example, I would say that any I18N effort that changes how ASCII usernames ([A-Za-z0-9...]) behave have gone too far down the road that causes damage to legacy systems. For passwords, there are also security aspects, since case folding reduces entropy. Maybe in some of these details we can find were we agree and disagree. /Simon From hotz@jpl.nasa.gov Wed Sep 25 16:06:14 2013 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 011B121F9E1A; Wed, 25 Sep 2013 16:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id er0H3XqWFzZ8; Wed, 25 Sep 2013 16:06:08 -0700 (PDT) Received: from mail.jpl.nasa.gov (mailhost.jpl.nasa.gov [128.149.139.109]) by ietfa.amsl.com (Postfix) with ESMTP id 4634621F9E01; Wed, 25 Sep 2013 16:06:05 -0700 (PDT) Received: from laphotz.jpl.nasa.gov (laphotz.jpl.nasa.gov [128.149.133.44]) (authenticated (0 bits)) by smtp.jpl.nasa.gov (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r8PN63hI028708 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Wed, 25 Sep 2013 16:06:04 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: "Henry B. Hotz" In-Reply-To: <87txharmne.fsf@latte.josefsson.org> Date: Wed, 25 Sep 2013 16:06:04 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51FEEC99.1020901@stpeter.im> <52090F96.30700@stpeter.im> <522E5CAA.5010902@stpeter.im> <5230B3B3.3040805@babelmonkeys.de> <87zjr2pmhs.fsf@latte.josefsson.org> <87txharmne.fsf@latte.josefsson.org> To: Simon Josefsson X-Mailer: Apple Mail (2.1510) X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized X-Mailman-Approved-At: Wed, 25 Sep 2013 18:01:17 -0700 Cc: "kitten@ietf.org" , Sam Hartman , "precis@ietf.org" Subject: Re: [precis] [kitten] I-D Action: draft-ietf-precis-saslprepbis-04.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 23:06:14 -0000 On Sep 24, 2013, at 1:27 PM, Simon Josefsson = wrote: > I disagree that an I18N document is the appropriate way to move the > Internet to case-insensitive usernames. +1 The arguments re case sensitivity are legitimate concerns, and should be = dealt with in the appropriate documents. =20 ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu