From y.oiwa@aist.go.jp Mon Jul 1 02:50:28 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 06E8221F9330 for ; Mon, 1 Jul 2013 02:50:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 RDpRtO6VQlkn for ; Mon, 1 Jul 2013 02:50:22 -0700 (PDT) Received: from na3sys010aog113.obsmtp.com (na3sys010aog113.obsmtp.com [74.125.245.94]) by ietfa.amsl.com (Postfix) with ESMTP id 3922F21F8925 for ; Mon, 1 Jul 2013 02:50:17 -0700 (PDT) Received: from mail-ve0-f180.google.com ([209.85.128.180]) (using TLSv1) by na3sys010aob113.postini.com ([74.125.244.12]) with SMTP ID DSNKUdFQ1/BIBDidxUe7UQzledTS1GUEctfA@postini.com; Mon, 01 Jul 2013 02:50:17 PDT Received: by mail-ve0-f180.google.com with SMTP id pa12so3549334veb.39 for ; Mon, 01 Jul 2013 02:50:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=google; h=mime-version:from:date:message-id:subject:to:content-type; bh=bKL1BhW8sRDEVyRJ53Fs93P052WeRURz/R1/CaO4QFA=; b=bnQsFc5nBr2NWLRzBOnive8S/LA8v3dl+Rh8QYeCjo6FG/7WWxOn8Ym/9EzHrsj52S dxzU+shvoFPZQsHOhk34U+V7Czz6ae8347m+TK042EMdkMHTJKh4YmnpGCk/nZJS/Z+U aapi+MgCju8rXNk/WIm2NJ9PFloDqGFWrXrLc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-gm-message-state; bh=bKL1BhW8sRDEVyRJ53Fs93P052WeRURz/R1/CaO4QFA=; b=lH53J+jcEuvcDIvhI1RTF/A4HZRMHDH+Vo3YX/qNh76HqCoY3N88LDujqhnAQLe/dn keF2SR5TjkFVQ6L+6Hl/ReNBtUOpVevwdr3kH0zwKjsjJtSaG99sJ91mBLIkYiK0SEJE rEYx2BHbeQ74Mpu93dLpmvFKf0R+BfqndXVHpTzD1U7NCfqXG3HgomF7FywMu1LTcnIq yJwRQ1V4VYZmDp5mDnGidJwr9VQ4Jc/lfvYlQsPwCgC7auKvpkH82UZF+oJaIj56Kany nDjrjCxVAQ8631tWPk07alGPVe2sris1c/kXrm3vtc6GD+mLmvolUZaztR200ysUUrMP zqhQ== X-Received: by 10.52.18.171 with SMTP id x11mr7816694vdd.92.1372672215003; Mon, 01 Jul 2013 02:50:15 -0700 (PDT) X-Received: by 10.52.18.171 with SMTP id x11mr7816692vdd.92.1372672214859; Mon, 01 Jul 2013 02:50:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.243.66 with HTTP; Mon, 1 Jul 2013 02:49:54 -0700 (PDT) From: Yutaka OIWA Date: Mon, 1 Jul 2013 18:49:54 +0900 Message-ID: To: precis@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmzdf55tnwd9iwarzJncH1Ibm4gBnIMwyAceRHEp+Gb0mKa+14vbGB7AkyCqGdRao0RFAtQ65qRhavASELbYBUbjXaBA6I60YP7cxQBg4F5S9M1NN3NucaeExd0PgpmrWRFPHwaJ8q9pdUyzgUOTPAoPmh5jg== Subject: [precis] About precis-httpauth-prep plan 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, 01 Jul 2013 09:50:28 -0000 Dear PRECIS list members, Corresponding to the request by Yoneya-san in Orlando, I am considering for a precis profile for HTTP-authentication. A straw-man I-D text is about to be prepared, but before submitting it, I'd like to have some comments on what is to be written. The following is a list-style summary of the possible content. If you have any suggestions/comments/whatever, these are really appreciated. Thanks, Yutaka [http-prep] = Importance of string preparation in HTTP authentications * needs for I17N * existing movements for I17N = applicability and scope * Generally applicable for all HTTP-(p7-)based authentications * It is only for the "default" algorithm * Specific authentication schemes MAY define alternative preparation to use (e.g. SASL-tunnelling, NTLM etc.) * Applicable for both Web and non-Web usages * Non-HTTP (e.g. HTML Form-based) authentications are out-of-scope * httpauth-prep will never require e.g. HTML-based auths to use this * however, it MAY be referred to/used by such applications if they want = technical requirements (non-normative) * ASCII transparency (MUST-requirement) * Every codepoint within U+0020 to U+007E MUST be preserved, and mapped to its 1-byte equivalent respectively. * This is a requirement for existing HTTP auth compatibility * Latin-1 preservation (SHOULD requirement) * codepoints U+00A1 to U+00FE SHOULD be preserved. * this enables non-crashing mapping from existing ISO-8859-1 user databases. * strong normalization * all representations (decomposed and composed) of every single "character" MUST be normalized to exactly one unicode character sequence. * NFC is to be taken. * Without this, virtually all "non-Basic" authentication may become broken with regard to internationalized username and passwords (e.g. Digest). * Not only passwords but also username will need this, as usernames are often hashed with passwords before key exchange. * Example: "Japanese katakana GA" = U+30AC or U+30AB U+3099 ... should be prepared to U+30AC. = Definition of preparation rule (the main part, normative) * To be written, a technical content = Discussions * case mapping * ASCII transparency rule automatically excludes any kinds of case mappings. * Is this OK? ... This is the "safer" rule for existing system compatibility * When prep does not use case mapping... * Case-sensitive existing systems: * Basic: OK * Digest etc: OK for ASCII username/passwords * Case-insensitive existing systems * Basic: OK (server-side may case-mapping if they want) * Digest etc: to require users to input their name/passwords in specific case (workaround relatively easy) * When prep forces use of case mapping... (e.g. lower-case mapping) * Case-sensitive existing systems: * Basic: NG for names/passwords containing mapped (capital) characters (workaround hard to imprement, sometimes impossible) * Digest etc: NG, ditto (workaround impossible) * Case-insensitive existing systems * Basic: OK * Digest etc: OK for ASCII username/passwords -- Yutaka OIWA, Ph.D. Leader, System Life-cycle Research Group Research Institute for Secure Systems (RISEC) National Institute of Advanced Industrial Science and Technology (AIST) Mail addresses: , OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B5] From stpeter@stpeter.im Tue Jul 2 12:57:02 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 0E14421F9B26; Tue, 2 Jul 2013 12:57:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.493 X-Spam-Level: X-Spam-Status: No, score=-102.493 tagged_above=-999 required=5 tests=[AWL=0.106, 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 myp8-84kIBjT; Tue, 2 Jul 2013 12:56:55 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 7D61A21F9AE0; Tue, 2 Jul 2013 12:56:55 -0700 (PDT) Received: from sjc-vpn5-1046.cisco.com (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 6D3D141101; Tue, 2 Jul 2013 13:57:35 -0600 (MDT) Message-ID: <51D33084.5060903@stpeter.im> Date: Tue, 02 Jul 2013 13:56:52 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Nico Williams References: <20130328033951.21028.2480.idtracker@ietfa.amsl.com> <515E4D5B.5050102@stpeter.im> <51648B46.2020905@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: kitten@ietf.org, precis@ietf.org Subject: Re: [precis] [kitten] Fwd: I-D Action: draft-ietf-precis-saslprepbis-01.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, 02 Jul 2013 19:57:03 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 5/3/13 1:39 PM, Nico Williams wrote: > Please forgive my apparent apathy. I lost track of this due to > business travel. And please forgive my delay in replying. It's good to know you're not apathetic. And as you can tell, we're proceeding rather slowly with this work. That doesn't mean it is unimportant. This recent example from the blogosphere might of interest: http://labs.spotify.com/2013/06/18/creative-usernames/ PRECIS might have helped those folks avoid some significant pain. > I'm not sure where the case mapping requirement for usernames came > from. Are you referring to global case mapping or local case mapping? > I guess it has something to do with the Turkish I and such. Yes, that is a nasty problem with even nastier consequences: http://gizmodo.com/382026/a-cellphones-missing-dot-kills-two-people-puts-three-more-in-jail Just to be clear, that's an issue of what we're calling local case mapping (where locale is taken into consideration). > I can't say I'm excited about this case mapping requirement; if > anything it strikes as silly. In general, the opinion so far has been that, say, StPeter is treated the same as stpeter when it comes to authentication and authorization based on usernames. Do you disagree? If so, why? For example, would you be inclined to leave this up to the protocol that uses SASL (say, IMAP or XMPP) instead of specifying it in SASLprepbis? > Why would we apply mappings to usernames (which are sent on the > wire) that we don't apply to passwords (which servers generally > don't get the plaintext of)? We need mappings for passwords to > make password entry reliable. The same does NOT apply to > usernames. My naïve perspective is that the combination of username and password is your credential (for password-based systems). If I provide StPeter and AUrwyaxDQ6rH68OefESL as my username and password, IMHO we sure want the password to be treated in a case-sensitive manner (since that reduces the possibility of false positives), whereas we want the username to be treated in a case-insensitive manner (since most application protocols treat StPeter@example.com as the same account as stpeter@example.com). > Also, looking at SASLprep and PRECIS, I see no mention of query > strings vs. display vs. storage. These distinctions matter. But > maybe I'm just failing to search for the right terms. Would you be so kind as to expand on that a bit? I'd like to make sure I understand what you mean by each of those terms. > Heck, we're not even told whether these rules should be applied by > the client, the server, or both. That is a very good point. This was something that bit us in RFC 3920 (for XMPP) and we've cleared that up in 6122bis: http://tools.ietf.org/html/draft-ietf-xmpp-6122bis-07#section-3 In my experience, we can *say* that the client needs to do this, but the server will need to do it anyway since it can't trust the client to do the right thing. However, for passwords (which, as you note, we hope the server never sees in plaintext) the client would need to enforce the rules. > Anyways, I'm for applying as few transformations as possible to > usernames on the *client* side and leaving the server to apply > RECOMMENDED, and a few REQUIRED rules for matching. I'd agree with that sentiment. > I don't see room for case folding in general, Even on the server side? Again, do you think it would be better to leave that up to the application? > but I do for specific cases (e.g., Turkish I handling). Unfortunately, local case mapping might be difficult for the server to perform because it doesn't necessarily have information about the locale of the user. So this is something that might best be handled at the client. > If this review is too late to make a difference, well, c'est la > vie. But do give the above some thought before rejecting my > comments for being late. Once more, I'm sorry I let this slip. You are not too late and your comments are important! 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/ iQIcBAEBAgAGBQJR0zCEAAoJEOoGpJErxa2p7xEQAJROFDCBZfnrP+9+h0qi29VL SBmWvTXkJTcLzRTUJja6bsTp75vqdFfckFT4apWeTuBrABktt8ny0/kNPAGue41H Q1avmi0y06oonL49zMbSiEmnPBakgOL75q5V1z218iV4w6cUFFh/AJtL36Dh8t// VZABcnuitQYknJbHR4HXZ0iAp4Aeo6EUHSkX9YSspf3IZJkXivXG3cCYNfw08B6p 5YrwXdsu4q7wH6bZcEDQBrQO1puaFG5/svOI/YnfvdIZH5ulYg0eeKOPp8VBVD4E exssCzttwTOGUDA2QLWovNHyHBKIHpfNAEiOvXj976UIPX5revaR6o0VUq7ekJfj uoaO+xvVAaKHI6huv1EUtVtbOxW248heZxci6eaQEYzheOrsyUInGgjpAYcMUdRy UjPmGtYQAgiZNIcLLCCdbZIjl8soF4rxu1LUBeVLkgW5widbHN1DXxvpHM499Kyf FyS2xC2WSDxV6c0oueFTG6VlXjevyCamAc4AjEycPTR+180or7OTaH841SSGAN5j IVRZVlK4CmYdDQTUAoPYacpYE4Y1jXqI+G5VZQVOIrlYoIGUu1RvujzJH1zDKBjQ 9uJyd6NtdTvc0ABBhoGLOiF/RcXzIwiLNHg1of5XVUWygs8KGUZxYtbepw0+nw08 JPzjpq3IyDXhavrqStFp =rkzA -----END PGP SIGNATURE----- From nico@cryptonector.com Tue Jul 2 16:20:47 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 4BD6A21F9A65; Tue, 2 Jul 2013 16:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[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 8owcRoTFaBWP; Tue, 2 Jul 2013 16:20:42 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id 595A321F9A64; Tue, 2 Jul 2013 16:20:42 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTP id BB6E1350082; Tue, 2 Jul 2013 16:20:41 -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:content-transfer-encoding; s= cryptonector.com; bh=HbeJvHav0w9/psSm4/vGDapOLKg=; b=o1hrgt7wuk3 kf+QchyviIbWGeZ4uHAtts/KRT0k+dc5LSHdlCiMztwkz+aju8QdL3k1ji3UJlDY eW2cds+glpoYZtYbXV1w+UO6wk4z9V8newt/XhCohxT7oGGZl2zi1MWPqjEfdxhN pNaXmHWvJJldPLqjrR3wEefWWTT5vf04= Received: from mail-ie0-f171.google.com (mail-ie0-f171.google.com [209.85.223.171]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTPSA id 811B335007A; Tue, 2 Jul 2013 16:20:41 -0700 (PDT) Received: by mail-ie0-f171.google.com with SMTP id qd12so13481003ieb.2 for ; Tue, 02 Jul 2013 16:20:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=lC0HEmJLMZnj8FmkH88L9Zcbdjv2KLA+WlKHIlDbH98=; b=L07hhB63G9weUjZ5wuIOXZEYWG/Vt1LfPf3U3FDUrAIHrU3gdDecTx/biIFxgxC7T3 lfPURQbYRivTgLarOLjhOUI8YaX+KxEcQbj1EpDLw5EY+fUelLPfoU0YJAPLefMxoCHV FyNX0gpjpgVkkAzrXcokXbhBy0Mg3rmGxfsjm+SXJQOC76X1wMb40jJq11ZvLHxHFQtN E31jrN82J/EdEq/GWb7Y02wKQv6w2UizQ2X3r1xYLcLQgEUCYX5F5gPnRjT1v984FT73 lgQ1xFrtAOr7ybdOlwc4SZV82qtS8dQ3dI7LX1q3jqqQgAaXxjgdzYFzWwF9T7yFRV3E PNVg== MIME-Version: 1.0 X-Received: by 10.50.128.36 with SMTP id nl4mr22805598igb.38.1372807240866; Tue, 02 Jul 2013 16:20:40 -0700 (PDT) Received: by 10.64.130.169 with HTTP; Tue, 2 Jul 2013 16:20:40 -0700 (PDT) In-Reply-To: <51D33084.5060903@stpeter.im> References: <20130328033951.21028.2480.idtracker@ietfa.amsl.com> <515E4D5B.5050102@stpeter.im> <51648B46.2020905@stpeter.im> <51D33084.5060903@stpeter.im> Date: Tue, 2 Jul 2013 18:20:40 -0500 Message-ID: From: Nico Williams To: Peter Saint-Andre Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: kitten@ietf.org, precis@ietf.org Subject: Re: [precis] [kitten] Fwd: I-D Action: draft-ietf-precis-saslprepbis-01.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, 02 Jul 2013 23:20:47 -0000 On Tue, Jul 2, 2013 at 2:56 PM, Peter Saint-Andre wrot= e: > On 5/3/13 1:39 PM, Nico Williams wrote: > >> Please forgive my apparent apathy. I lost track of this due to >> business travel. > > And please forgive my delay in replying. It's good to know you're not > apathetic. And as you can tell, we're proceeding rather slowly with > this work. That doesn't mean it is unimportant. This recent example > from the blogosphere might of interest: > > http://labs.spotify.com/2013/06/18/creative-usernames/ > > PRECIS might have helped those folks avoid some significant pain. > >> I'm not sure where the case mapping requirement for usernames came >> from. > > Are you referring to global case mapping or local case mapping? > >> I guess it has something to do with the Turkish I and such. > > Yes, that is a nasty problem with even nastier consequences: > > http://gizmodo.com/382026/a-cellphones-missing-dot-kills-two-people-puts-= three-more-in-jail ! But that can't apply here. Or, if anything, case mappings makes it more likely. Let's say I'm logged in in some app and it shows the username I typed in, but because of case mapping some typos are tolerated, so the username shown could offend someone. Whereas if I'm required to type my username exactly one way (not including NF) then that can't happen. So if anything that link indicates we should not have case mappings here... :) > Just to be clear, that's an issue of what we're calling local case > mapping (where locale is taken into consideration). > >> I can't say I'm excited about this case mapping requirement; if >> anything it strikes as silly. > > In general, the opinion so far has been that, say, StPeter is treated > the same as stpeter when it comes to authentication and authorization > based on usernames. Do you disagree? If so, why? For example, would > you be inclined to leave this up to the protocol that uses SASL (say, > IMAP or XMPP) instead of specifying it in SASLprepbis? I think it'd be nice if *servers* got to choose whether to do this. The principle here is that the server should make right when it comes to the username. This means that clients should be pretty much able to send just about anything as a username and let the server figure it out. Whether it's a server application or the mechanisms (or SASL library) that applies such rules is a different story, and one I don't think I care much about here. >> Why would we apply mappings to usernames (which are sent on the >> wire) that we don't apply to passwords (which servers generally >> don't get the plaintext of)? We need mappings for passwords to >> make password entry reliable. The same does NOT apply to >> usernames. > > My na=C3=AFve perspective is that the combination of username and passwor= d > is your credential (for password-based systems). If I provide StPeter > and AUrwyaxDQ6rH68OefESL as my username and password, IMHO we sure > want the password to be treated in a case-sensitive manner (since that > reduces the possibility of false positives), whereas we want the > username to be treated in a case-insensitive manner (since most > application protocols treat StPeter@example.com as the same account as > stpeter@example.com). It's not just false positives: many sites require multiple character classes in password data, but case folding would nullify part of such policies :) If the user's password must survive with case intact then the user must be able to enter it portably (i.e., on many devices). Surely asking the same of usernames is not an undue additional burden for the user. Still, I don't mind if some site wants to have case-insensitive usernames. I just don't want us to impose that policy on *all* sites. Once again I'm thinking of online games, ones where people often convey ideas (usually comical ones) via their usernames. Providing the most freedom possible here seems like the right thing to do; requiring case-insensitivity is denying some freedom. >> Also, looking at SASLprep and PRECIS, I see no mention of query >> strings vs. display vs. storage. These distinctions matter. But >> maybe I'm just failing to search for the right terms. > > Would you be so kind as to expand on that a bit? I'd like to make sure > I understand what you mean by each of those terms. Sure. Query string =3D=3D a string entered by a user in some UI, to be matched against some thing's name. Display string =3D=3D a thing's name, as displayed to users in UIs. Storage string =3D=3D a thing's name as stored, and usually this is the canonical form of the thing's name. For example, "nico" might be a query name for my Kerberos principal, but the display name might be nico@CRYPTONECTOR.COM, and the storage string will be in some format we don't really care about here but roughly equivalent to the display string form. To continue the example, if my KDC was case-insensitive then "Nico" would also work as a query string; what I get for the display string might either match the query string or the storage string, and the storage string could be any of the many case variants of "nico" (but almost certainly would be case-folded in many implementations). The relevance here is that we should apply as few transformations as possible to *query* strings on the client-side and just send them. What transformations a server applies then can be up to the server and/or the mechanism (e.g., a federated mechanism might need to apply transformations specified by it). SASLprep-like stringpreps are very useful, especially for *passwords* because passwords may need to be in canonical form because they are used as inputs to client-side cryptographic functions (e.g., Digest). But they are less relevant for usernames, unless they too are used as inputs to client-side cryptographic functions (e.g., as salts), but even then the username query string might still be sent as-is separately to the server. >> Heck, we're not even told whether these rules should be applied by >> the client, the server, or both. > > That is a very good point. This was something that bit us in RFC 3920 > (for XMPP) and we've cleared that up in 6122bis: This is where the distinction between query, display, and storage (or canonical) forms comes in. > http://tools.ietf.org/html/draft-ietf-xmpp-6122bis-07#section-3 > > In my experience, we can *say* that the client needs to do this, but > the server will need to do it anyway since it can't trust the client > to do the right thing. However, for passwords (which, as you note, we > hope the server never sees in plaintext) the client would need to > enforce the rules. Correct, as to the last part. I don't think we need the client to apply this to anything that isn't an input to a cryptograhic function on the client-side -- just send the darned thing as is. >> Anyways, I'm for applying as few transformations as possible to >> usernames on the *client* side and leaving the server to apply >> RECOMMENDED, and a few REQUIRED rules for matching. > > I'd agree with that sentiment. Great. >> I don't see room for case folding in general, > > Even on the server side? Again, do you think it would be better to > leave that up to the application? I'd leave it to the site/mechanism/app -- whatever's appropriate. >> but I do for specific cases (e.g., Turkish I handling). > > Unfortunately, local case mapping might be difficult for the server to > perform because it doesn't necessarily have information about the > locale of the user. So this is something that might best be handled at > the client. Ah, well, if we're dealing in Unicode we could send a language tag in the string. That's a non-starter. But note that the server probably has a username database anyways, so it knows the relevant language at account-creation time (or should anyways). Nico -- From stpeter@stpeter.im Wed Jul 10 11:21:59 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 4D30A21F9EAA for ; Wed, 10 Jul 2013 11:21:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.531 X-Spam-Level: X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=0.068, 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 awcWRG9248Ae for ; Wed, 10 Jul 2013 11:21:54 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id E8EC321F9FA4 for ; Wed, 10 Jul 2013 11:21:48 -0700 (PDT) Received: from ergon.local (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 030F1413F5; Wed, 10 Jul 2013 12:22:54 -0600 (MDT) Message-ID: <51DDA63A.7080400@stpeter.im> Date: Wed, 10 Jul 2013 12:21:46 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: precis@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [precis] About precis-httpauth-prep plan 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, 10 Jul 2013 18:21:59 -0000 On 7/1/13 3:49 AM, Yutaka OIWA wrote: > Dear PRECIS list members, > > Corresponding to the request by Yoneya-san in Orlando, > I am considering for a precis profile for HTTP-authentication. Hi Yutaka, My apologies for the delayed reply. I see that you have already posted your I-D. I can provide detailed feedback, but first I wonder: why not just use draft-ietf-precis-saslprepbis for usernames and passwords, instead of defining a new PRECIS profile for HTTP authentication? Is there something special about HTTP authentication that makes the profile defined in draft-ietf-precis-saslprepbis unusable? Also, it seems preferable to use the same profile for both SASL and HTTP (shared code, common user expectations, etc.). Thanks! Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Wed Jul 10 12:01: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 0F18721F8808; Wed, 10 Jul 2013 12:01:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.065, 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 wskkcO8VVZHn; Wed, 10 Jul 2013 12:01:37 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 94CD421F8D0D; Wed, 10 Jul 2013 12:00:44 -0700 (PDT) Received: from ergon.local (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id EE87E413F5; Wed, 10 Jul 2013 13:01:49 -0600 (MDT) Message-ID: <51DDAF59.4040800@stpeter.im> Date: Wed, 10 Jul 2013 13:00:41 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Nico Williams References: <20130328033951.21028.2480.idtracker@ietfa.amsl.com> <515E4D5B.5050102@stpeter.im> <51648B46.2020905@stpeter.im> <51D33084.5060903@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: kitten@ietf.org, precis@ietf.org Subject: Re: [precis] [kitten] Fwd: I-D Action: draft-ietf-precis-saslprepbis-01.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, 10 Jul 2013 19:01:43 -0000 On 7/2/13 5:20 PM, Nico Williams wrote: > On Tue, Jul 2, 2013 at 2:56 PM, Peter Saint-Andre wrote: >> On 5/3/13 1:39 PM, Nico Williams wrote: >> >>> Please forgive my apparent apathy. I lost track of this due to >>> business travel. >> >> And please forgive my delay in replying. It's good to know you're not >> apathetic. And as you can tell, we're proceeding rather slowly with >> this work. That doesn't mean it is unimportant. This recent example >> from the blogosphere might of interest: >> >> http://labs.spotify.com/2013/06/18/creative-usernames/ >> >> PRECIS might have helped those folks avoid some significant pain. >> >>> I'm not sure where the case mapping requirement for usernames came >>> from. >> >> Are you referring to global case mapping or local case mapping? >> >>> I guess it has something to do with the Turkish I and such. >> >> Yes, that is a nasty problem with even nastier consequences: >> >> http://gizmodo.com/382026/a-cellphones-missing-dot-kills-two-people-puts-three-more-in-jail > > ! > > But that can't apply here. Or, if anything, case mappings makes it > more likely. Let's say I'm logged in in some app and it shows the > username I typed in, but because of case mapping some typos are > tolerated, so the username shown could offend someone. Whereas if I'm > required to type my username exactly one way (not including NF) then > that can't happen. So if anything that link indicates we should not > have case mappings here... :) > >> Just to be clear, that's an issue of what we're calling local case >> mapping (where locale is taken into consideration). >> >>> I can't say I'm excited about this case mapping requirement; if >>> anything it strikes as silly. >> >> In general, the opinion so far has been that, say, StPeter is treated >> the same as stpeter when it comes to authentication and authorization >> based on usernames. Do you disagree? If so, why? For example, would >> you be inclined to leave this up to the protocol that uses SASL (say, >> IMAP or XMPP) instead of specifying it in SASLprepbis? > > I think it'd be nice if *servers* got to choose whether to do this. > The principle here is that the server should make right when it comes > to the username. This means that clients should be pretty much able > to send just about anything as a username and let the server figure it > out. > > Whether it's a server application or the mechanisms (or SASL library) > that applies such rules is a different story, and one I don't think I > care much about here. Ah, I see. It seems to me that there are numerous layers here: 1. SASL (including preparation and comparison rules) 2. The application protocol that's using SASL (e.g., IMAP) 3. A software implementation of the application protocol, which likely embeds or links to a SASL implementation (e.g., dovecot) 4. A deployment of said software implementation (e.g., example.net) By "server" I think you mean a deployment. Correct? Rather than legislating in saslprepbis that all application protocols shall leave casemapping up to implementations or deployments, I think that it would be reasonable for the specification of an application protocol using SASL (e.g., draft-ietf-xmpp-6122bis) to recommend or require casemapping behavior for all implementations or deployments of that application protocol, or to leave such decisions up to the implementation or deployment. For example, perhaps the XMPP spec would say "all implementations shall perform case mapping, full stop" whereas the IMAP spec might leave that up to implementations or deployments. >>> Why would we apply mappings to usernames (which are sent on the >>> wire) that we don't apply to passwords (which servers generally >>> don't get the plaintext of)? We need mappings for passwords to >>> make password entry reliable. The same does NOT apply to >>> usernames. >> >> My naïve perspective is that the combination of username and password >> is your credential (for password-based systems). If I provide StPeter >> and AUrwyaxDQ6rH68OefESL as my username and password, IMHO we sure >> want the password to be treated in a case-sensitive manner (since that >> reduces the possibility of false positives), whereas we want the >> username to be treated in a case-insensitive manner (since most >> application protocols treat StPeter@example.com as the same account as >> stpeter@example.com). > > It's not just false positives: many sites require multiple character > classes in password data, but case folding would nullify part of such > policies :) Indeed! > If the user's password must survive with case intact then the user > must be able to enter it portably (i.e., on many devices). Surely > asking the same of usernames is not an undue additional burden for the > user. > > Still, I don't mind if some site wants to have case-insensitive > usernames. I just don't want us to impose that policy on *all* sites. I now agree that I don't want the SASLprepbis spec to impose that policy on all sites, but I also don't think that I want the SASLprepbis spec to impose deployment-layer policies on all application protocols. However, I do think it's reasonable for the SASLprepbis spec to say "specifications for application protocols that use SASLprepbis must specify the casemapping policy for that application protocol; options include but are not limited to legislating behavior for all implementations or leaving casemapping up to particular deployments". > Once again I'm thinking of online games, ones where people often > convey ideas (usually comical ones) via their usernames. Providing > the most freedom possible here seems like the right thing to do; > requiring case-insensitivity is denying some freedom. The SASLprepbis document is about comparison and what gets sent over the wire. An application might preserve case for user interface purposes but still lowercase "StPeter" to "stpeter" for comparison purposes during authentication. See also the nickname spec (what you're talking about sounds more like a nickname or screen name than a username, but that might be a distinction without a difference): http://tools.ietf.org/id/draft-ietf-precis-nickname-05.txt >>> Also, looking at SASLprep and PRECIS, I see no mention of query >>> strings vs. display vs. storage. These distinctions matter. But >>> maybe I'm just failing to search for the right terms. >> >> Would you be so kind as to expand on that a bit? I'd like to make sure >> I understand what you mean by each of those terms. > > Sure. > > Query string == a string entered by a user in some UI, to be matched > against some thing's name. > > Display string == a thing's name, as displayed to users in UIs. > > Storage string == a thing's name as stored, and usually this is the > canonical form of the thing's name. > > For example, "nico" might be a query name for my Kerberos principal, > but the display name might be nico@CRYPTONECTOR.COM, and the storage > string will be in some format we don't really care about here but > roughly equivalent to the display string form. > > To continue the example, if my KDC was case-insensitive then "Nico" > would also work as a query string; what I get for the display string > might either match the query string or the storage string, and the > storage string could be any of the many case variants of "nico" (but > almost certainly would be case-folded in many implementations). > > The relevance here is that we should apply as few transformations as > possible to *query* strings on the client-side and just send them. > What transformations a server applies then can be up to the server > and/or the mechanism (e.g., a federated mechanism might need to apply > transformations specified by it). > > SASLprep-like stringpreps are very useful, especially for *passwords* > because passwords may need to be in canonical form because they are > used as inputs to client-side cryptographic functions (e.g., Digest). > But they are less relevant for usernames, unless they too are used as > inputs to client-side cryptographic functions (e.g., as salts), but > even then the username query string might still be sent as-is > separately to the server. Thanks for clarifying. >>> Heck, we're not even told whether these rules should be applied by >>> the client, the server, or both. >> >> That is a very good point. This was something that bit us in RFC 3920 >> (for XMPP) and we've cleared that up in 6122bis: > > This is where the distinction between query, display, and storage (or > canonical) forms comes in. Yes. >> http://tools.ietf.org/html/draft-ietf-xmpp-6122bis-07#section-3 >> >> In my experience, we can *say* that the client needs to do this, but >> the server will need to do it anyway since it can't trust the client >> to do the right thing. However, for passwords (which, as you note, we >> hope the server never sees in plaintext) the client would need to >> enforce the rules. > > Correct, as to the last part. I don't think we need the client to > apply this to anything that isn't an input to a cryptograhic function > on the client-side -- just send the darned thing as is. > >>> Anyways, I'm for applying as few transformations as possible to >>> usernames on the *client* side and leaving the server to apply >>> RECOMMENDED, and a few REQUIRED rules for matching. >> >> I'd agree with that sentiment. > > Great. > >>> I don't see room for case folding in general, >> >> Even on the server side? Again, do you think it would be better to >> leave that up to the application? > > I'd leave it to the site/mechanism/app -- whatever's appropriate. OK, good. That's consistent with what I typed earlier in this message. >>> but I do for specific cases (e.g., Turkish I handling). >> >> Unfortunately, local case mapping might be difficult for the server to >> perform because it doesn't necessarily have information about the >> locale of the user. So this is something that might best be handled at >> the client. > > Ah, well, if we're dealing in Unicode we could send a language tag in > the string. That's a non-starter. > > But note that the server probably has a username database anyways, so > it knows the relevant language at account-creation time (or should > anyways). Quite possible. In XMPP the client can tell the server its locale, but that might not be supported yet in other application protocols... Peter -- Peter Saint-Andre https://stpeter.im/ From internet-drafts@ietf.org Wed Jul 10 12:42: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 C991B21F9DA8; Wed, 10 Jul 2013 12:42:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.531 X-Spam-Level: X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 p9b7Xj4g9uMZ; Wed, 10 Jul 2013 12:42:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C11D921F9D8B; Wed, 10 Jul 2013 12:42:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130710194229.4141.77958.idtracker@ietfa.amsl.com> Date: Wed, 10 Jul 2013 12:42:29 -0700 Cc: precis@ietf.org Subject: [precis] I-D Action: draft-ietf-precis-nickname-06.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, 10 Jul 2013 19:42:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Preparation and Comparison of Internation= alized Strings Working Group of the IETF. Title : Preparation and Comparison of Nicknames Author(s) : Peter Saint-Andre Filename : draft-ietf-precis-nickname-06.txt Pages : 8 Date : 2013-07-10 Abstract: This document describes how to prepare and compare Unicode strings representing nicknames, primarily for use within textual chatrooms. This profile is intended to be used by messaging and text conferencing technologies such as the Extensible Messaging and Presence Protocol (XMPP), the Message Session Relay Protocol (MSRP), and Centralized Conferencing (XCON). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-precis-nickname There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-precis-nickname-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-precis-nickname-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From stpeter@stpeter.im Wed Jul 10 12: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 36ADB21F9D5E for ; Wed, 10 Jul 2013 12:47:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 kwE0PuANo48v for ; Wed, 10 Jul 2013 12:47:07 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 82A1F21F9D56 for ; Wed, 10 Jul 2013 12:47:07 -0700 (PDT) Received: from ergon.local (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 6B8BB413F5; Wed, 10 Jul 2013 13:48:14 -0600 (MDT) Message-ID: <51DDBA39.2060706@stpeter.im> Date: Wed, 10 Jul 2013 13:47:05 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: precis@ietf.org References: <20130710194229.4141.77958.idtracker@ietfa.amsl.com> In-Reply-To: <20130710194229.4141.77958.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [precis] I-D Action: draft-ietf-precis-nickname-06.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, 10 Jul 2013 19:47:12 -0000 This document completed WGLC in December, but it has slowly gone out of sync with the framework specification (e.g., with regard to the order of operations). This small update brings it back into sync. I leave it up to the chairs whether this requires a new Last Call, or some other form of working group review. Peter On 7/10/13 1:42 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 Nicknames > Author(s) : Peter Saint-Andre > Filename : draft-ietf-precis-nickname-06.txt > Pages : 8 > Date : 2013-07-10 > > Abstract: > This document describes how to prepare and compare Unicode strings > representing nicknames, primarily for use within textual chatrooms. > This profile is intended to be used by messaging and text > conferencing technologies such as the Extensible Messaging and > Presence Protocol (XMPP), the Message Session Relay Protocol (MSRP), > and Centralized Conferencing (XCON). > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-precis-nickname > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-precis-nickname-06 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-precis-nickname-06 > > > 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 > From stpeter@stpeter.im Wed Jul 10 13:03:24 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 D1C3521F9E18 for ; Wed, 10 Jul 2013 13:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.058, 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 FN+qBtxd-ap7 for ; Wed, 10 Jul 2013 13:03:19 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 6D79121F9DA1 for ; Wed, 10 Jul 2013 13:03:19 -0700 (PDT) Received: from ergon.local (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id BCEE8413F5; Wed, 10 Jul 2013 14:04:22 -0600 (MDT) Message-ID: <51DDBE01.6090605@stpeter.im> Date: Wed, 10 Jul 2013 14:03:13 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "precis@ietf.org" X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [precis] updated framework I-D 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, 10 Jul 2013 20:03:24 -0000 I have received no feedback about the (IMHO small) ordering issues I raised several weeks ago: http://www.ietf.org/mail-archive/web/precis/current/msg00456.html http://www.ietf.org/mail-archive/web/precis/current/msg00459.html Because the I-D submission deadline is fast approaching, I will soon submit a revised I-D incorporating my proposed changes (as well as numerous fixes to the codepoint table). We can discuss these as open issues at IETF 87 in Berlin. Thanks! Peter -- Peter Saint-Andre https://stpeter.im/ From internet-drafts@ietf.org Wed Jul 10 13:07: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 48B6221F9EC6; Wed, 10 Jul 2013 13:07:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 sJ+aXY-bc2QP; Wed, 10 Jul 2013 13:07:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CD42321F9970; Wed, 10 Jul 2013 13:07:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130710200725.14735.40771.idtracker@ietfa.amsl.com> Date: Wed, 10 Jul 2013 13:07:25 -0700 Cc: precis@ietf.org Subject: [precis] I-D Action: 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, 10 Jul 2013 20:07:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Preparation and Comparison of Internation= alized Strings Working Group of the IETF. Title : PRECIS Framework: Preparation and Comparison of Internat= ionalized Strings in Application Protocols Author(s) : Peter Saint-Andre Marc Blanchet Filename : draft-ietf-precis-framework-09.txt Pages : 65 Date : 2013-07-10 Abstract: Application protocols using Unicode code points in protocol strings need to properly prepare such strings in order to perform valid comparison operations (e.g., for purposes of authentication or authorization). This document defines a framework enabling application protocols to perform the preparation and comparison of internationalized strings (a.k.a. "PRECIS") in a way that depends on the properties of Unicode code points and thus is agile with respect to versions of Unicode. As a result, this framework provides a more sustainable approach to the handling of internationalized strings than the previous framework, known as Stringprep (RFC 3454). A specification that reuses this framework can either directly use the PRECIS string classes or subclass the PRECIS string classes as needed. This framework takes an approach similar to the revised internationalized domain names (IDNs) in applications (IDNA) technology (RFC 5890, RFC 5891, RFC 5892, RFC 5893, RFC 5894) and thus adheres to the high-level design goals described in the IAB's recommendations regarding IDNs (RFC 4690), albeit for application technologies other than the Domain Name System (DNS). This document obsoletes RFC 3454. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-precis-framework There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-precis-framework-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-precis-framework-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From marc.blanchet@viagenie.ca Wed Jul 10 13:42:19 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 7D65321F9D4B for ; Wed, 10 Jul 2013 13:42:19 -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 Nj++VmBFmTOH for ; Wed, 10 Jul 2013 13:42:18 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6019421F871D for ; Wed, 10 Jul 2013 13:42:18 -0700 (PDT) Received: from h227.viagenie.ca (h227.viagenie.ca [206.123.31.227]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 0347C47131; Wed, 10 Jul 2013 16:42:07 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Marc Blanchet In-Reply-To: <51DDA63A.7080400@stpeter.im> Date: Wed, 10 Jul 2013 16:42:05 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51DDA63A.7080400@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1508) Cc: precis@ietf.org Subject: Re: [precis] About precis-httpauth-prep plan 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, 10 Jul 2013 20:42:19 -0000 Le 2013-07-10 =E0 14:21, Peter Saint-Andre a =E9crit = : > On 7/1/13 3:49 AM, Yutaka OIWA wrote: >> Dear PRECIS list members, >>=20 >> Corresponding to the request by Yoneya-san in Orlando, >> I am considering for a precis profile for HTTP-authentication. >=20 > Hi Yutaka, >=20 > My apologies for the delayed reply. I see that you have already posted > your I-D. I can provide detailed feedback, but first I wonder: why not > just use draft-ietf-precis-saslprepbis for usernames and passwords, > instead of defining a new PRECIS profile for HTTP authentication? Is > there something special about HTTP authentication that makes the = profile > defined in draft-ietf-precis-saslprepbis unusable? Also, it seems > preferable to use the same profile for both SASL and HTTP (shared = code, > common user expectations, etc.). same credentials carried over multiple apps... Marc. >=20 > Thanks! >=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 From stpeter@stpeter.im Wed Jul 10 13:49:02 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 DE55121F9E96 for ; Wed, 10 Jul 2013 13:49:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.543 X-Spam-Level: X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.056, 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 btapo3uwFMZi for ; Wed, 10 Jul 2013 13:48:57 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id CB93F21F9E7C for ; Wed, 10 Jul 2013 13:48:57 -0700 (PDT) Received: from ergon.local (unknown [128.107.239.235]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 5D172413F5; Wed, 10 Jul 2013 14:50:04 -0600 (MDT) Message-ID: <51DDC8B7.3050509@stpeter.im> Date: Wed, 10 Jul 2013 14:48:55 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Marc Blanchet References: <51DDA63A.7080400@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: precis@ietf.org Subject: Re: [precis] About precis-httpauth-prep plan 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, 10 Jul 2013 20:49:03 -0000 On 7/10/13 2:42 PM, Marc Blanchet wrote: > > Le 2013-07-10 à 14:21, Peter Saint-Andre a écrit : > >> On 7/1/13 3:49 AM, Yutaka OIWA wrote: >>> Dear PRECIS list members, >>> >>> Corresponding to the request by Yoneya-san in Orlando, >>> I am considering for a precis profile for HTTP-authentication. >> >> Hi Yutaka, >> >> My apologies for the delayed reply. I see that you have already posted >> your I-D. I can provide detailed feedback, but first I wonder: why not >> just use draft-ietf-precis-saslprepbis for usernames and passwords, >> instead of defining a new PRECIS profile for HTTP authentication? Is >> there something special about HTTP authentication that makes the profile >> defined in draft-ietf-precis-saslprepbis unusable? Also, it seems >> preferable to use the same profile for both SASL and HTTP (shared code, >> common user expectations, etc.). > > same credentials carried over multiple apps... Yes, that too! :-) Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Wed Jul 10 13:49:38 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 DE06421F9E85; Wed, 10 Jul 2013 13:49:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.545 X-Spam-Level: X-Spam-Status: No, score=-102.545 tagged_above=-999 required=5 tests=[AWL=0.054, 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 wS6+WdMbYZur; Wed, 10 Jul 2013 13:49:34 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 82E8B21F9E7C; Wed, 10 Jul 2013 13:49:34 -0700 (PDT) Received: from ergon.local (unknown [128.107.239.235]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A8EA8413F5; Wed, 10 Jul 2013 14:50:32 -0600 (MDT) Message-ID: <51DDC8D3.5060808@stpeter.im> Date: Wed, 10 Jul 2013 14:49:23 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Nico Williams References: <20130328033951.21028.2480.idtracker@ietfa.amsl.com> <515E4D5B.5050102@stpeter.im> <51648B46.2020905@stpeter.im> <51D33084.5060903@stpeter.im> <51DDAF59.4040800@stpeter.im> In-Reply-To: <51DDAF59.4040800@stpeter.im> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org, precis@ietf.org Subject: Re: [precis] [kitten] Fwd: I-D Action: draft-ietf-precis-saslprepbis-01.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, 10 Jul 2013 20:49:39 -0000 Hi Nico, I've looked at this a bit further. Proposed text changes below... On 7/10/13 1:00 PM, Peter Saint-Andre wrote: > On 7/2/13 5:20 PM, Nico Williams wrote: >> On Tue, Jul 2, 2013 at 2:56 PM, Peter Saint-Andre >> wrote: >>> On 5/3/13 1:39 PM, Nico Williams wrote: >>> >>>> Please forgive my apparent apathy. I lost track of this due >>>> to business travel. >>> >>> And please forgive my delay in replying. It's good to know >>> you're not apathetic. And as you can tell, we're proceeding >>> rather slowly with this work. That doesn't mean it is >>> unimportant. This recent example from the blogosphere might of >>> interest: >>> >>> http://labs.spotify.com/2013/06/18/creative-usernames/ >>> >>> PRECIS might have helped those folks avoid some significant >>> pain. >>> >>>> I'm not sure where the case mapping requirement for usernames >>>> came from. >>> >>> Are you referring to global case mapping or local case >>> mapping? >>> >>>> I guess it has something to do with the Turkish I and such. >>> >>> Yes, that is a nasty problem with even nastier consequences: >>> >>> http://gizmodo.com/382026/a-cellphones-missing-dot-kills-two-people-puts-three-more-in-jail >> >> >>> ! >> >> But that can't apply here. Or, if anything, case mappings makes >> it more likely. Let's say I'm logged in in some app and it shows >> the username I typed in, but because of case mapping some typos >> are tolerated, so the username shown could offend someone. >> Whereas if I'm required to type my username exactly one way (not >> including NF) then that can't happen. So if anything that link >> indicates we should not have case mappings here... :) >> >>> Just to be clear, that's an issue of what we're calling local >>> case mapping (where locale is taken into consideration). >>> >>>> I can't say I'm excited about this case mapping requirement; >>>> if anything it strikes as silly. >>> >>> In general, the opinion so far has been that, say, StPeter is >>> treated the same as stpeter when it comes to authentication and >>> authorization based on usernames. Do you disagree? If so, why? >>> For example, would you be inclined to leave this up to the >>> protocol that uses SASL (say, IMAP or XMPP) instead of >>> specifying it in SASLprepbis? >> >> I think it'd be nice if *servers* got to choose whether to do >> this. The principle here is that the server should make right >> when it comes to the username. This means that clients should be >> pretty much able to send just about anything as a username and >> let the server figure it out. >> >> Whether it's a server application or the mechanisms (or SASL >> library) that applies such rules is a different story, and one I >> don't think I care much about here. > > Ah, I see. > > It seems to me that there are numerous layers here: > > 1. SASL (including preparation and comparison rules) > > 2. The application protocol that's using SASL (e.g., IMAP) > > 3. A software implementation of the application protocol, which > likely embeds or links to a SASL implementation (e.g., dovecot) > > 4. A deployment of said software implementation (e.g., > example.net) > > By "server" I think you mean a deployment. Correct? > > Rather than legislating in saslprepbis that all application > protocols shall leave casemapping up to implementations or > deployments, I think that it would be reasonable for the > specification of an application protocol using SASL (e.g., > draft-ietf-xmpp-6122bis) to recommend or require casemapping > behavior for all implementations or deployments of that application > protocol, or to leave such decisions up to the implementation or > deployment. For example, perhaps the XMPP spec would say "all > implementations shall perform case mapping, full stop" whereas the > IMAP spec might leave that up to implementations or deployments. Here is what I suggest in Section 2.2 of draft-ietf-precis-saslprepbis: OLD 3. Uppercase and titlecase characters MUST be mapped to their lowercase equivalents. NEW 3. Uppercase and titlecase characters MAY be mapped to their lowercase equivalents. Then add the following sentence at the end of that section: Application protocols that use this profile MUST specify whether case mapping or additional mapping is to be applied by implementations or deployments of that protocol. Does that seem acceptable? Peter -- Peter Saint-Andre https://stpeter.im/ From nico@cryptonector.com Wed Jul 10 14:20: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 185CE21F9A30; Wed, 10 Jul 2013 14:20:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.377 X-Spam-Level: X-Spam-Status: No, score=-2.377 tagged_above=-999 required=5 tests=[AWL=-0.400, 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 MBTph78rDOOq; Wed, 10 Jul 2013 14:20:48 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 2483221F99FA; Wed, 10 Jul 2013 14:20:48 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTP id 14C0E678089; Wed, 10 Jul 2013 14:20:41 -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=iduQE6CaJQL5QIfe2giP ql/rWXk=; b=Z94b2l3FWuZNEyAZWH58fuDfWPtQsQaU3Vj2HHWO6D8anh1f9P3f POJMzx1nsWWElLixc8OEfa8rEWkWtT3sYz6GckMTZuOXy50BaY4ni5bjcDvGKlXb qSBNQDBjYT8CU7hd/w2QwTEooB5Cb3ge7C7aB77hODTp1thhinAzENo= Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTPSA id 028AB67808D; Wed, 10 Jul 2013 14:20:18 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id ey16so12904569wid.5 for ; Wed, 10 Jul 2013 14:20:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LABTzHsiRrtfmVtvWTjrzGDA5KQk5U4Lvcqd1pK/beU=; b=iRwnUdexvtUSdi8iboWJWlZ9IKdIeNNv84nLIxZmeAIm+p/aAVtF0mjBnRBQ18wLNL 0vAtO1x708yUIvLzjD+/SZ845SzkfldQx2dFoXExmoSWQLdAvdyRBCZqWVVHilH0pPE8 6wXOYOt2Q6akxPnTBUHcbNWMCDQpHqQnxqZXTIsUk/MgHIXA6SmPbkESYzsDAUSWCbYI 4UAyOrgs8c1WccPhRljlT+fjg93vLsLTMNRyxR3Dkt9gqWaQbJFvI97pVwwdSdAWIkW9 R++XGSmNjxiHj35pZKlj7DbJ9MTzYP65jdoQdGyFprslHulUsc5yt8NM9dAg0L1yGAPl w73g== MIME-Version: 1.0 X-Received: by 10.194.240.169 with SMTP id wb9mr18554445wjc.90.1373491217156; Wed, 10 Jul 2013 14:20:17 -0700 (PDT) Received: by 10.217.38.138 with HTTP; Wed, 10 Jul 2013 14:20:16 -0700 (PDT) In-Reply-To: <51DDAF59.4040800@stpeter.im> References: <20130328033951.21028.2480.idtracker@ietfa.amsl.com> <515E4D5B.5050102@stpeter.im> <51648B46.2020905@stpeter.im> <51D33084.5060903@stpeter.im> <51DDAF59.4040800@stpeter.im> Date: Wed, 10 Jul 2013 16:20:16 -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: I-D Action: draft-ietf-precis-saslprepbis-01.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, 10 Jul 2013 21:20:53 -0000 On Wed, Jul 10, 2013 at 2:00 PM, Peter Saint-Andre wrote: > On 7/2/13 5:20 PM, Nico Williams wrote: >> I think it'd be nice if *servers* got to choose whether to do this. >> The principle here is that the server should make right when it comes >> to the username. This means that clients should be pretty much able >> to send just about anything as a username and let the server figure it >> out. >> >> Whether it's a server application or the mechanisms (or SASL library) >> that applies such rules is a different story, and one I don't think I >> care much about here. > > Ah, I see. > > It seems to me that there are numerous layers here: Yes. Lots of layers. Consider SASL/GS1 and SASL/GS2 as well. > By "server" I think you mean a deployment. Correct? Generally, yes. > Rather than legislating in saslprepbis that all application protocols > shall leave casemapping up to implementations or deployments, I think > that it would be reasonable for the specification of an application > protocol using SASL (e.g., draft-ietf-xmpp-6122bis) to recommend or > require casemapping behavior for all implementations or deployments of > that application protocol, or to leave such decisions up to the > implementation or deployment. For example, perhaps the XMPP spec would > say "all implementations shall perform case mapping, full stop" whereas > the IMAP spec might leave that up to implementations or deployments. We could have: - apps specify whether to case fold - apps specify that the server can casefold if it wants That's fine with me. Note that the second comes naturally from speaking of query/display/store syntaxes. The client only deals in query and display syntaxes for usernames, so the server can make right. >> Still, I don't mind if some site wants to have case-insensitive >> usernames. I just don't want us to impose that policy on *all* sites. > > I now agree that I don't want the SASLprepbis spec to impose that policy > on all sites, but I also don't think that I want the SASLprepbis spec to > impose deployment-layer policies on all application protocols. However, > I do think it's reasonable for the SASLprepbis spec to say > "specifications for application protocols that use SASLprepbis must > specify the casemapping policy for that application protocol; options > include but are not limited to legislating behavior for all > implementations or leaving casemapping up to particular deployments". No, not MUST, but MAY is fine, and I might go along with SHOULD. First, we'd be informing authors of app protocol specs -- we can use RFC2119 language for that, but it's hard to enforce -- this language doesn't deal with interop. >> Once again I'm thinking of online games, ones where people often >> convey ideas (usually comical ones) via their usernames. Providing >> the most freedom possible here seems like the right thing to do; >> requiring case-insensitivity is denying some freedom. > > The SASLprepbis document is about comparison and what gets sent over the > wire. An application might preserve case for user interface purposes but > still lowercase "StPeter" to "stpeter" for comparison purposes during > authentication. The only party doing comparisons is the server, therefore the only party that should have to apply any sort of normalization should also be the server -- otherwise if the client also normalizes *prevents* some names from being useful/usable. Normalizations that preserve equivalence can be OK on the client side (e.g., Unicode normalization), but case folding loses information. This principle, that the party doing comparisons/lookups (because the server might be comparing hashes for all we know) is the party that should normalize, is a very useful principle here. It follows from distinguishing types of name syntax. If multiple parties have to do these comparisons/lookups *then* we may need to say more about who normalizes and when (and why). > See also the nickname spec (what you're talking about sounds more like > a nickname or screen name than a username, but that might be a > distinction without a difference): Remember that what I have in mind is a bevy of online games where users are free to pick usernames we'd *never* consider valid in an enterprise environment, like "Joe 6-pack (I'm the best)". (For an example you can see for yourself, download bzflag and play for a bit. It's an open source game with user-contributed maps, user-run servers, and so on. Its users tend to have weird names -- these aren't nicknames, they *are* the usernames, it's what you type in at login time.) >> I'd leave it to the site/mechanism/app -- whatever's appropriate. > > OK, good. That's consistent with what I typed earlier in this message. Well, except I want to be able to leave it to the server if the app protocol authors think that's fine. I don't want to prescribe that app protocols must prescribe which normalization the clients apply. I don't mind if some app protocols do. But I want it to be possible that the client doesn't have to. In fact, I'd prefer if SASL clients *never* had to normalize usernames *except* when they must use them for salting purposes (but still send the unmodified original as the actual username) -- it's far simpler and most flexible this way. >> Ah, well, if we're dealing in Unicode we could send a language tag in >> the string. That's a non-starter. >> >> But note that the server probably has a username database anyways, so >> it knows the relevant language at account-creation time (or should >> anyways). > > Quite possible. In XMPP the client can tell the server its locale, but > that might not be supported yet in other application protocols... Right, but I think the server still has enough context. In the worst case scenario it might have to try N different normalizations and lookups, but I kinda doubt N will ever be larger than 1. Nico -- From marc.blanchet@viagenie.ca Wed Jul 10 15:07: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 107CE21F9CE6; Wed, 10 Jul 2013 15:07:57 -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 5c8DpvNmdxAS; Wed, 10 Jul 2013 15:07:56 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0045F21F9CCC; Wed, 10 Jul 2013 15:07:55 -0700 (PDT) Received: from h227.viagenie.ca (h227.viagenie.ca [206.123.31.227]) by jazz.viagenie.ca (Postfix) with ESMTPSA id AA630403ED; Wed, 10 Jul 2013 18:07:46 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Marc Blanchet In-Reply-To: <51DDC8D3.5060808@stpeter.im> Date: Wed, 10 Jul 2013 18:07:37 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0DFFEBDE-F6FB-4C9E-BFBA-0181234C11A2@viagenie.ca> References: <20130328033951.21028.2480.idtracker@ietfa.amsl.com> <515E4D5B.5050102@stpeter.im> <51648B46.2020905@stpeter.im> <51D33084.5060903@stpeter.im> <51DDAF59.4040800@stpeter.im> <51DDC8D3.5060808@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1508) Cc: kitten@ietf.org, Nico Williams , precis@ietf.org Subject: Re: [precis] [kitten] Fwd: I-D Action: draft-ietf-precis-saslprepbis-01.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, 10 Jul 2013 22:07:57 -0000 Le 2013-07-10 =E0 16:49, Peter Saint-Andre a =E9crit = : > Hi Nico, I've looked at this a bit further. Proposed text changes = below... >=20 > On 7/10/13 1:00 PM, Peter Saint-Andre wrote: >> On 7/2/13 5:20 PM, Nico Williams wrote: >>> On Tue, Jul 2, 2013 at 2:56 PM, Peter Saint-Andre >>> wrote: >>>> On 5/3/13 1:39 PM, Nico Williams wrote: >>>>=20 >>>>> Please forgive my apparent apathy. I lost track of this due >>>>> to business travel. >>>>=20 >>>> And please forgive my delay in replying. It's good to know >>>> you're not apathetic. And as you can tell, we're proceeding >>>> rather slowly with this work. That doesn't mean it is >>>> unimportant. This recent example from the blogosphere might of >>>> interest: >>>>=20 >>>> http://labs.spotify.com/2013/06/18/creative-usernames/ >>>>=20 >>>> PRECIS might have helped those folks avoid some significant >>>> pain. >>>>=20 >>>>> I'm not sure where the case mapping requirement for usernames >>>>> came from. >>>>=20 >>>> Are you referring to global case mapping or local case >>>> mapping? >>>>=20 >>>>> I guess it has something to do with the Turkish I and such. >>>>=20 >>>> Yes, that is a nasty problem with even nastier consequences: >>>>=20 >>>> = http://gizmodo.com/382026/a-cellphones-missing-dot-kills-two-people-puts-t= hree-more-in-jail >>>=20 >>>=20 >>>>=20 > ! >>>=20 >>> But that can't apply here. Or, if anything, case mappings makes >>> it more likely. Let's say I'm logged in in some app and it shows >>> the username I typed in, but because of case mapping some typos >>> are tolerated, so the username shown could offend someone. >>> Whereas if I'm required to type my username exactly one way (not >>> including NF) then that can't happen. So if anything that link >>> indicates we should not have case mappings here... :) >>>=20 >>>> Just to be clear, that's an issue of what we're calling local >>>> case mapping (where locale is taken into consideration). >>>>=20 >>>>> I can't say I'm excited about this case mapping requirement; >>>>> if anything it strikes as silly. >>>>=20 >>>> In general, the opinion so far has been that, say, StPeter is >>>> treated the same as stpeter when it comes to authentication and >>>> authorization based on usernames. Do you disagree? If so, why? >>>> For example, would you be inclined to leave this up to the >>>> protocol that uses SASL (say, IMAP or XMPP) instead of >>>> specifying it in SASLprepbis? >>>=20 >>> I think it'd be nice if *servers* got to choose whether to do >>> this. The principle here is that the server should make right >>> when it comes to the username. This means that clients should be >>> pretty much able to send just about anything as a username and >>> let the server figure it out. >>>=20 >>> Whether it's a server application or the mechanisms (or SASL >>> library) that applies such rules is a different story, and one I >>> don't think I care much about here. >>=20 >> Ah, I see. >>=20 >> It seems to me that there are numerous layers here: >>=20 >> 1. SASL (including preparation and comparison rules) >>=20 >> 2. The application protocol that's using SASL (e.g., IMAP) >>=20 >> 3. A software implementation of the application protocol, which >> likely embeds or links to a SASL implementation (e.g., dovecot) >>=20 >> 4. A deployment of said software implementation (e.g., >> example.net) >>=20 >> By "server" I think you mean a deployment. Correct? >>=20 >> Rather than legislating in saslprepbis that all application >> protocols shall leave casemapping up to implementations or >> deployments, I think that it would be reasonable for the >> specification of an application protocol using SASL (e.g., >> draft-ietf-xmpp-6122bis) to recommend or require casemapping >> behavior for all implementations or deployments of that application >> protocol, or to leave such decisions up to the implementation or >> deployment. For example, perhaps the XMPP spec would say "all >> implementations shall perform case mapping, full stop" whereas the >> IMAP spec might leave that up to implementations or deployments. >=20 > Here is what I suggest in Section 2.2 of = draft-ietf-precis-saslprepbis: >=20 > OLD > 3. Uppercase and titlecase characters MUST be mapped to their > lowercase equivalents. >=20 > NEW > 3. Uppercase and titlecase characters MAY be mapped to their > lowercase equivalents. >=20 > Then add the following sentence at the end of that section: >=20 > Application protocols that use this profile MUST specify whether = case > mapping or additional mapping is to be applied by implementations or > deployments of that protocol. I have a hard time thinking that, especially for credentials, app = protocol 1 chooses no mapping and app protocol 2 chooses mapping and = that both are using the SASL layer below. Looks like looking for = trouble here. no? Marc. >=20 > Does that seem acceptable? >=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 From nico@cryptonector.com Wed Jul 10 15:37: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 6BD2411E8144; Wed, 10 Jul 2013 15:37:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.341 X-Spam-Level: X-Spam-Status: No, score=-2.341 tagged_above=-999 required=5 tests=[AWL=-0.364, 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 QcXCQZpteEtO; Wed, 10 Jul 2013 15:37:07 -0700 (PDT) Received: from homiemail-a54.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id 8258611E8124; Wed, 10 Jul 2013 15:37:07 -0700 (PDT) Received: from homiemail-a54.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a54.g.dreamhost.com (Postfix) with ESMTP id A025540122425; Wed, 10 Jul 2013 15:37:06 -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=FpPp/OwLxlRo2gFKh12Z 8xAUimU=; b=azeIUAyoHm0jTfMX0vqREqPQ7bk/iDO+CoYXHaI67kFofV6bwN6w SFEsehocUWJHCVUBK7kCKD9gzHr8LyyY3cT+JEtzMsO80+UEYz2YwcTHspvydLgO D/BUXISfQohGNOrdmG+8JsIW1g2NuDIG1YC8GLTr8NXMiM7Kmmp2LPU= Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a54.g.dreamhost.com (Postfix) with ESMTPSA id 206924012241C; Wed, 10 Jul 2013 15:37:05 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id hq4so11957093wib.12 for ; Wed, 10 Jul 2013 15:37:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tze3ce0Qt5Hee+R1/X3HqY6oVMIgcDe6ypuNt5HGK5k=; b=o5ZXRlwqnAsnXlgvVgdDBAxTtIR8TpRVe590Gd1RebtQPMNoqYkyWahkPaxXyM+EBM rGdXLib4W2+MB1Hxr5Lm6H9hJ2m3GuYrRoQ8jofZ809IFyEq6nWE6cxherysml96NsZo owiKbPVQqCNtD5MYtL9np3FBDb4Mti/xu7S/x9AU/En88nrg3q6bleduHOAJfivtgQRa HUkXJaUKM6inmWsMc2qFS9wur6JQuGbQynzdd65MD79U94KZlruUhn5N00G4eHnsca4h x28H737GCR/zbVK26cbBJzAI+Rae2SmwWFCHaR8JL9yNMy4KaJH5j3aUqGNyyuhxCYhK j/AQ== MIME-Version: 1.0 X-Received: by 10.194.240.169 with SMTP id wb9mr18703595wjc.90.1373495824379; Wed, 10 Jul 2013 15:37:04 -0700 (PDT) Received: by 10.217.38.138 with HTTP; Wed, 10 Jul 2013 15:37:04 -0700 (PDT) In-Reply-To: <51DDC8D3.5060808@stpeter.im> References: <20130328033951.21028.2480.idtracker@ietfa.amsl.com> <515E4D5B.5050102@stpeter.im> <51648B46.2020905@stpeter.im> <51D33084.5060903@stpeter.im> <51DDAF59.4040800@stpeter.im> <51DDC8D3.5060808@stpeter.im> Date: Wed, 10 Jul 2013 17:37:04 -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: I-D Action: draft-ietf-precis-saslprepbis-01.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, 10 Jul 2013 22:37:12 -0000 On Wed, Jul 10, 2013 at 3:49 PM, Peter Saint-Andre wrote: > Here is what I suggest in Section 2.2 of draft-ietf-precis-saslprepbis: > > OLD > 3. Uppercase and titlecase characters MUST be mapped to their > lowercase equivalents. > > NEW > 3. Uppercase and titlecase characters MAY be mapped to their > lowercase equivalents. Do we need to give advice regarding the use of query strings for cryptographic protocols? E.g., usernames as salts. I think we do. Specifically, *mechanisms* must specify what normalizations (and let's provide a nice one for them to all use) for such purposes. > Then add the following sentence at the end of that section: > > Application protocols that use this profile MUST specify whether case > mapping or additional mapping is to be applied by implementations or > deployments of that protocol. > > Does that seem acceptable? Yes. Nico -- From nico@cryptonector.com Wed Jul 10 15:41:50 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 DFDE421F9CC2; Wed, 10 Jul 2013 15:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.064 X-Spam-Level: X-Spam-Status: No, score=-2.064 tagged_above=-999 required=5 tests=[AWL=-0.087, 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 waIVwK7Djhvn; Wed, 10 Jul 2013 15:41:46 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id E49F821F9CBF; Wed, 10 Jul 2013 15:41:45 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTP id 91778508072; Wed, 10 Jul 2013 15:41:45 -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:content-transfer-encoding; s= cryptonector.com; bh=jVYMAzIE+etpnZVZXMwwGBVOXx0=; b=aOB1g4X1Wal 0zelm8gp92mCFe/Z2wPe95yC87beYJhV4Ji7B3bdMJEx531V9bKVFeXRYcxC5iRf Y6kncLmEusRvoOHto9fNgxJ2SWhrEKElVYhAYA5Od8/ZILVc9QLOvp+EsnyA74Yl +HK6B369EG3o0YI20RciqtN/W5K3uRHY= 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-a16.g.dreamhost.com (Postfix) with ESMTPSA id 19CF9508063; Wed, 10 Jul 2013 15:41:44 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id n57so6432727wev.28 for ; Wed, 10 Jul 2013 15:41:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=skX79uj6vm5EdVWFb6wH3W0CE0/m/h9nD8JfX7q7dos=; b=Z9SaMhifEBpUAfn3b887qlsanp4kmM3/xBy2FHbhRi9hyIpQVOh/KqsrWpZ7yTPGX5 UcowRmPKiENDQBfKjM4ZeNTp+R+EXO3RcLpb9l6ClGKbkQSPD2q6PDCqbnXZGxOAOFzp w1qu4jcd8zMXwk8PaLB0777FKvY5fWRv5oknuv/ztRPfWeIg5PrIz8QuIRiR6/G1eAkU 63aOFlvDi/6e3FpANGVFRS4R4rqJbU3OIJluBjsd7QzGmnTAA7QCZiYnI01YsKbOYOIA SeqgfsmERT6VYVR7770oyx3GBFs20QTWOgQboUBjBo8GPn1E9f6ljLMwR5LfRB+1GOxb YBxg== MIME-Version: 1.0 X-Received: by 10.180.84.70 with SMTP id w6mr18243964wiy.36.1373496103676; Wed, 10 Jul 2013 15:41:43 -0700 (PDT) Received: by 10.217.38.138 with HTTP; Wed, 10 Jul 2013 15:41:43 -0700 (PDT) In-Reply-To: <0DFFEBDE-F6FB-4C9E-BFBA-0181234C11A2@viagenie.ca> References: <20130328033951.21028.2480.idtracker@ietfa.amsl.com> <515E4D5B.5050102@stpeter.im> <51648B46.2020905@stpeter.im> <51D33084.5060903@stpeter.im> <51DDAF59.4040800@stpeter.im> <51DDC8D3.5060808@stpeter.im> <0DFFEBDE-F6FB-4C9E-BFBA-0181234C11A2@viagenie.ca> Date: Wed, 10 Jul 2013 17:41:43 -0500 Message-ID: From: Nico Williams To: Marc Blanchet Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: kitten@ietf.org, precis@ietf.org Subject: Re: [precis] [kitten] Fwd: I-D Action: draft-ietf-precis-saslprepbis-01.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, 10 Jul 2013 22:41:51 -0000 On Wed, Jul 10, 2013 at 5:07 PM, Marc Blanchet wrote: > Le 2013-07-10 =C3=A0 16:49, Peter Saint-Andre a =C3= =A9crit : >> Here is what I suggest in Section 2.2 of draft-ietf-precis-saslprepbis: >> >> OLD >> 3. Uppercase and titlecase characters MUST be mapped to their >> lowercase equivalents. >> >> NEW >> 3. Uppercase and titlecase characters MAY be mapped to their >> lowercase equivalents. >> >> Then add the following sentence at the end of that section: >> >> Application protocols that use this profile MUST specify whether case >> mapping or additional mapping is to be applied by implementations or >> deployments of that protocol. > > I have a hard time thinking that, especially for credentials, app protoco= l 1 chooses no mapping and app protocol 2 chooses mapping and that both are= using the SASL layer below. Looks like looking for trouble here. no? The mechanism on the server side absolutely must apply whatever normalization is appropriate for it. The client should not have to. The app protocol could specify whether the client does or does not have to, I don't mind that. But it'd be silly to specify something that conflicts with whatever the mechanism will apply, so, that's a good point. All the more reason to have the app do nothing with usernames. Just pass them to the mechanism. Let the mechanism work it out. The mechanism on the client side should only normalize usernames for the purposes of generating salts. Also, the mechanism on the client side may want to apply Unicode normalization if the client has an input mode that produces NFD (say) when most servers happen to not implement a normalization (though they should) and expect NFC (say, which mostly they do). Nico -- From y.oiwa@aist.go.jp Wed Jul 10 18:20:52 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 7059621F922A for ; Wed, 10 Jul 2013 18:20:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 jr6z8jBV321u for ; Wed, 10 Jul 2013 18:20:48 -0700 (PDT) Received: from na3sys010aog107.obsmtp.com (na3sys010aog107.obsmtp.com [74.125.245.82]) by ietfa.amsl.com (Postfix) with ESMTP id AA23921F8F4A for ; Wed, 10 Jul 2013 18:20:41 -0700 (PDT) Received: from mail-ve0-f173.google.com ([209.85.128.173]) (using TLSv1) by na3sys010aob107.postini.com ([74.125.244.12]) with SMTP ID DSNKUd4IZK8+FFehGohcWvzJXK41W6Wg+pvm@postini.com; Wed, 10 Jul 2013 18:20:46 PDT Received: by mail-ve0-f173.google.com with SMTP id jw11so6756807veb.32 for ; Wed, 10 Jul 2013 18:20:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=yd2DWmHK9MJf091p0garo+YVEkgwDxAgDY0I1klPbp8=; b=caiQayiuR+dW+Uz/gZrahy8f4tnNg/wKyTY0Zt/JsVg3we6UBwremU07nwk4A1+QTn P/zNG054qGM3ynnUV1xGHjVVAZVqiQ/JLPLPkBJ8vmpK2CbS5UYjuTgC2sZHyY2uIKad hoRi0HaBulG80/+kzfkxCHfizInv4shhlFM+c= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=yd2DWmHK9MJf091p0garo+YVEkgwDxAgDY0I1klPbp8=; b=TQDzT5tYKR248Uybgx/TrCpmqKPnjr8FxS2yc0sa0/Nody6vNNyaEba4omlFw9mDBW v0Vok5b26cYuOA4lfrvMYnm2tnZ2QO2QSBIfrOONgXIYv9CD9kXzfPOrSI+g8/rWPbAJ zNkILXaLExI9abE1PEmlSxAe+7Mq9zm0JDlVQvXQkPE9eeEK83uipd8dOquCN4JvUdgM tu83jYSmck+QzTA+kzu+GwN7ADPuv06bEyTyri61OE83xxU4gYmt7bGbIeSwbBDLIrXK fQeaFdA4AeuaWHNpaG98XwBmCqLNf/ijUDSHVTn3BOoC26q4Sbxdu4L3erExuuG87KfR Nvgw== X-Received: by 10.58.86.70 with SMTP id n6mr20828845vez.8.1373505635496; Wed, 10 Jul 2013 18:20:35 -0700 (PDT) X-Received: by 10.58.86.70 with SMTP id n6mr20828842vez.8.1373505635373; Wed, 10 Jul 2013 18:20:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.230.101 with HTTP; Wed, 10 Jul 2013 18:20:15 -0700 (PDT) In-Reply-To: <51DDA63A.7080400@stpeter.im> References: <51DDA63A.7080400@stpeter.im> From: Yutaka OIWA Date: Thu, 11 Jul 2013 10:20:15 +0900 Message-ID: To: Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlg/sgOdAtsAopexdjV9mNLfPF5wwwkLAtD8YrfPz1/WIE1WDCuWMgzRX+X9eFjzLivAZDx+pXhDxnV0zDUF9S0sOaoXQDEqvrCxGDnzA6XIu+I01b9idYwztmcwERSfYWwDZbjCjxe39c5uOcp1KbBXnSEwg== Cc: precis@ietf.org Subject: Re: [precis] About precis-httpauth-prep plan 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, 11 Jul 2013 01:20:52 -0000 > Is there something special about HTTP authentication that makes the profile > defined in draft-ietf-precis-saslprepbis unusable? Simply speaking, case mapping. To interoperate with existing user DBs, and to use with case-sensitive existing systems, case mapping for general-purpose HTTP authentication is a MUST-NOT. We also expect that existing ASCII-only systems will not implement the HTTPAUTHprep, and the existing HTTP authentication is case-sensitive (or ASCII octetwise), we SHOULD keep ASCII transparency, which means case-sensitive. As you might have already read, HTTPAUTHprep will be one of the simplest PRECIS profile. (Possibly it may be called a SIMPLE precis profile instead.) Given that there is a simple-enough case-insensitive profile, I will be happy to merge with it. 2013/7/11 Peter Saint-Andre : > On 7/1/13 3:49 AM, Yutaka OIWA wrote: >> Dear PRECIS list members, >> >> Corresponding to the request by Yoneya-san in Orlando, >> I am considering for a precis profile for HTTP-authentication. > > Hi Yutaka, > > My apologies for the delayed reply. I see that you have already posted > your I-D. I can provide detailed feedback, but first I wonder: why not > just use draft-ietf-precis-saslprepbis for usernames and passwords, > instead of defining a new PRECIS profile for HTTP authentication? Is > there something special about HTTP authentication that makes the profile > defined in draft-ietf-precis-saslprepbis unusable? Also, it seems > preferable to use the same profile for both SASL and HTTP (shared code, > common user expectations, etc.). > > Thanks! > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ > > > _______________________________________________ > precis mailing list > precis@ietf.org > https://www.ietf.org/mailman/listinfo/precis -- Yutaka OIWA, Ph.D. Leader, System Life-cycle Research Group Research Institute for Secure Systems (RISEC) National Institute of Advanced Industrial Science and Technology (AIST) Mail addresses: , OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B5] From alexey.melnikov@isode.com Thu Jul 11 00:43: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 B86C521F964C; Thu, 11 Jul 2013 00:43:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.134 X-Spam-Level: X-Spam-Status: No, score=-102.134 tagged_above=-999 required=5 tests=[AWL=0.465, 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 nDweO68jQXPy; Thu, 11 Jul 2013 00:43:26 -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 0049F21F963F; Thu, 11 Jul 2013 00:43:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1373528604; d=isode.com; s=selector; i=@isode.com; bh=na+NfkCLyLJlyodF4CjeH3dPwkTCRpDFHslhujzTljw=; 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=ZPUIjKPIMA257gf3W8XN9vPbBJU0g5UVpv2826rXEo/AmqTO8oCc98nnnHKhJZltTMy8FA ZYghQyAoeBHOM+olo8A/YBKSJK4fQxC681XOF/WF1nI/jPo/Cxzj3DbEKevxAfUd+sIyHJ 3Ci8BrrFvvh3qtBhr1Bu2GiPhHKlg1s=; Received: from [10.243.90.242] ((unknown) [212.183.128.181]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 11 Jul 2013 08:43:24 +0100 X-SMTP-Protocol-Errors: NORDNS References: <20130328033951.21028.2480.idtracker@ietfa.amsl.com> <515E4D5B.5050102@stpeter.im> <51648B46.2020905@stpeter.im> <51D33084.5060903@stpeter.im> <51DDAF59.4040800@stpeter.im> <51DDC8D3.5060808@stpeter.im> In-Reply-To: <51DDC8D3.5060808@stpeter.im> Message-Id: <0145BE0C-08DA-48D3-9F25-77714EDBA2D6@isode.com> X-Mailer: iPhone Mail (10A523) From: Alexey Melnikov Date: Thu, 11 Jul 2013 08:44:59 +0100 To: Peter Saint-Andre MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "kitten@ietf.org" , Nico Williams , "precis@ietf.org" Subject: Re: [precis] [kitten] Fwd: I-D Action: draft-ietf-precis-saslprepbis-01.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, 11 Jul 2013 07:43:26 -0000 On 10 Jul 2013, at 21:49, Peter Saint-Andre wrote: >> Rather than legislating in saslprepbis that all application >> protocols shall leave casemapping up to implementations or >> deployments, I think that it would be reasonable for the >> specification of an application protocol using SASL (e.g., >> draft-ietf-xmpp-6122bis) to recommend or require casemapping >> behavior for all implementations or deployments of that application >> protocol, or to leave such decisions up to the implementation or >> deployment. For example, perhaps the XMPP spec would say "all >> implementations shall perform case mapping, full stop" whereas the >> IMAP spec might leave that up to implementations or deployments. > > Here is what I suggest in Section 2.2 of draft-ietf-precis-saslprepbis: > > OLD > 3. Uppercase and titlecase characters MUST be mapped to their > lowercase equivalents. > > NEW > 3. Uppercase and titlecase characters MAY be mapped to their > lowercase equivalents. > > Then add the following sentence at the end of that section: > > Application protocols that use this profile MUST specify whether case > mapping or additional mapping is to be applied by implementations or > deployments of that protocol. > > Does that seem acceptable? Yes. From stpeter@stpeter.im Thu Jul 11 10:49:20 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 8A3AC21E804C; Thu, 11 Jul 2013 10:49:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.543 X-Spam-Level: X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.056, 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 znZy9h8yzxP6; Thu, 11 Jul 2013 10:49:15 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 4E98421F9B2A; Thu, 11 Jul 2013 10:49:12 -0700 (PDT) Received: from sjc-vpn2-1401.cisco.com (unknown [128.107.239.235]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2E5FA41400; Thu, 11 Jul 2013 11:50:21 -0600 (MDT) Message-ID: <51DEF015.70608@stpeter.im> Date: Thu, 11 Jul 2013 11:49:09 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Alexey Melnikov References: <20130328033951.21028.2480.idtracker@ietfa.amsl.com> <515E4D5B.5050102@stpeter.im> <51648B46.2020905@stpeter.im> <51D33084.5060903@stpeter.im> <51DDAF59.4040800@stpeter.im> <51DDC8D3.5060808@stpeter.im> <0145BE0C-08DA-48D3-9F25-77714EDBA2D6@isode.com> In-Reply-To: <0145BE0C-08DA-48D3-9F25-77714EDBA2D6@isode.com> X-Enigmail-Version: 1.5.1 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: I-D Action: draft-ietf-precis-saslprepbis-01.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, 11 Jul 2013 17:49:20 -0000 On 7/11/13 1:44 AM, Alexey Melnikov wrote: > On 10 Jul 2013, at 21:49, Peter Saint-Andre wrote: > >>> Rather than legislating in saslprepbis that all application >>> protocols shall leave casemapping up to implementations or >>> deployments, I think that it would be reasonable for the >>> specification of an application protocol using SASL (e.g., >>> draft-ietf-xmpp-6122bis) to recommend or require casemapping >>> behavior for all implementations or deployments of that application >>> protocol, or to leave such decisions up to the implementation or >>> deployment. For example, perhaps the XMPP spec would say "all >>> implementations shall perform case mapping, full stop" whereas the >>> IMAP spec might leave that up to implementations or deployments. >> >> Here is what I suggest in Section 2.2 of draft-ietf-precis-saslprepbis: >> >> OLD >> 3. Uppercase and titlecase characters MUST be mapped to their >> lowercase equivalents. >> >> NEW >> 3. Uppercase and titlecase characters MAY be mapped to their >> lowercase equivalents. >> >> Then add the following sentence at the end of that section: >> >> Application protocols that use this profile MUST specify whether case >> mapping or additional mapping is to be applied by implementations or >> deployments of that protocol. >> >> Does that seem acceptable? > > Yes. Thanks for the feedback. I was wondering last night whether we want to add some guidance or recommendations on this topic, or truly just leave it up to those who define application protocols. (For example, we could say something about balancing interoperability and user expectations.) Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Thu Jul 11 12:19:50 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 716B521F9E95 for ; Thu, 11 Jul 2013 12:19:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.545 X-Spam-Level: X-Spam-Status: No, score=-102.545 tagged_above=-999 required=5 tests=[AWL=0.054, 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 XDBGJSk2Dmum for ; Thu, 11 Jul 2013 12:19:45 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 4F6BF21F9D28 for ; Thu, 11 Jul 2013 12:19:45 -0700 (PDT) Received: from sjc-vpn2-1401.cisco.com (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B97C841403; Thu, 11 Jul 2013 13:20:54 -0600 (MDT) Message-ID: <51DF054E.4050003@stpeter.im> Date: Thu, 11 Jul 2013 13:19:42 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Yutaka OIWA References: <51DDA63A.7080400@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: precis@ietf.org Subject: Re: [precis] About precis-httpauth-prep plan 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, 11 Jul 2013 19:19:50 -0000 On 7/10/13 7:20 PM, Yutaka OIWA wrote: >> Is there something special about HTTP authentication that makes the profile >> defined in draft-ietf-precis-saslprepbis unusable? > > Simply speaking, case mapping. > To interoperate with existing user DBs, and to use with > case-sensitive existing systems, case mapping for > general-purpose HTTP authentication is a MUST-NOT. > We also expect that existing ASCII-only systems will > not implement the HTTPAUTHprep, and the existing > HTTP authentication is case-sensitive (or ASCII octetwise), > we SHOULD keep ASCII transparency, which means case-sensitive. > > As you might have already read, HTTPAUTHprep will be > one of the simplest PRECIS profile. > (Possibly it may be called a SIMPLE precis profile instead.) > Given that there is a simple-enough case-insensitive > profile, I will be happy to merge with it. Hi Yutaka, Your feedback is consistent with the feedback that Nico and Jeffrey have provided about the replacement for SASLprep. Since we will change draft-ietf-precis-saslprepbis to make casemapping completely optional, I think we will be able to define a general-purpose HTTP-auth profile of that spec which forbids casemapping (whereas, say, XMPP might require or recommend casemapping). Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Thu Jul 11 12:27:58 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 6795E21F9E05; Thu, 11 Jul 2013 12:27:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.547 X-Spam-Level: X-Spam-Status: No, score=-102.547 tagged_above=-999 required=5 tests=[AWL=0.052, 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 QC0wOGrJwPpr; Thu, 11 Jul 2013 12:27:54 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 8078921F9E13; Thu, 11 Jul 2013 12:27:52 -0700 (PDT) Received: from sjc-vpn2-1401.cisco.com (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 04AF841403; Thu, 11 Jul 2013 13:29:01 -0600 (MDT) Message-ID: <51DF0735.8000006@stpeter.im> Date: Thu, 11 Jul 2013 13:27:49 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Marc Blanchet References: <20130328033951.21028.2480.idtracker@ietfa.amsl.com> <515E4D5B.5050102@stpeter.im> <51648B46.2020905@stpeter.im> <51D33084.5060903@stpeter.im> <51DDAF59.4040800@stpeter.im> <51DDC8D3.5060808@stpeter.im> <0DFFEBDE-F6FB-4C9E-BFBA-0181234C11A2@viagenie.ca> In-Reply-To: <0DFFEBDE-F6FB-4C9E-BFBA-0181234C11A2@viagenie.ca> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: kitten@ietf.org, Nico Williams , precis@ietf.org Subject: Re: [precis] [kitten] Fwd: I-D Action: draft-ietf-precis-saslprepbis-01.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, 11 Jul 2013 19:27:58 -0000 On 7/10/13 4:07 PM, Marc Blanchet wrote: > Le 2013-07-10 à 16:49, Peter Saint-Andre a écrit > : > >> Hi Nico, I've looked at this a bit further. Proposed text changes >> below... >> >> On 7/10/13 1:00 PM, Peter Saint-Andre wrote: >>> On 7/2/13 5:20 PM, Nico Williams wrote: >>>> On Tue, Jul 2, 2013 at 2:56 PM, Peter Saint-Andre >>>> wrote: >>>>> On 5/3/13 1:39 PM, Nico Williams wrote: >>>>> >>>>>> Please forgive my apparent apathy. I lost track of this >>>>>> due to business travel. >>>>> >>>>> And please forgive my delay in replying. It's good to know >>>>> you're not apathetic. And as you can tell, we're proceeding >>>>> rather slowly with this work. That doesn't mean it is >>>>> unimportant. This recent example from the blogosphere might >>>>> of interest: >>>>> >>>>> http://labs.spotify.com/2013/06/18/creative-usernames/ >>>>> >>>>> PRECIS might have helped those folks avoid some significant >>>>> pain. >>>>> >>>>>> I'm not sure where the case mapping requirement for >>>>>> usernames came from. >>>>> >>>>> Are you referring to global case mapping or local case >>>>> mapping? >>>>> >>>>>> I guess it has something to do with the Turkish I and >>>>>> such. >>>>> >>>>> Yes, that is a nasty problem with even nastier consequences: >>>>> >>>>> http://gizmodo.com/382026/a-cellphones-missing-dot-kills-two-people-puts-three-more-in-jail >>>> >>>> >>>>> >> >>>>> ! >>>> >>>> But that can't apply here. Or, if anything, case mappings >>>> makes it more likely. Let's say I'm logged in in some app and >>>> it shows the username I typed in, but because of case mapping >>>> some typos are tolerated, so the username shown could offend >>>> someone. Whereas if I'm required to type my username exactly >>>> one way (not including NF) then that can't happen. So if >>>> anything that link indicates we should not have case mappings >>>> here... :) >>>> >>>>> Just to be clear, that's an issue of what we're calling >>>>> local case mapping (where locale is taken into >>>>> consideration). >>>>> >>>>>> I can't say I'm excited about this case mapping >>>>>> requirement; if anything it strikes as silly. >>>>> >>>>> In general, the opinion so far has been that, say, StPeter >>>>> is treated the same as stpeter when it comes to >>>>> authentication and authorization based on usernames. Do you >>>>> disagree? If so, why? For example, would you be inclined to >>>>> leave this up to the protocol that uses SASL (say, IMAP or >>>>> XMPP) instead of specifying it in SASLprepbis? >>>> >>>> I think it'd be nice if *servers* got to choose whether to do >>>> this. The principle here is that the server should make right >>>> when it comes to the username. This means that clients should >>>> be pretty much able to send just about anything as a username >>>> and let the server figure it out. >>>> >>>> Whether it's a server application or the mechanisms (or SASL >>>> library) that applies such rules is a different story, and one >>>> I don't think I care much about here. >>> >>> Ah, I see. >>> >>> It seems to me that there are numerous layers here: >>> >>> 1. SASL (including preparation and comparison rules) >>> >>> 2. The application protocol that's using SASL (e.g., IMAP) >>> >>> 3. A software implementation of the application protocol, which >>> likely embeds or links to a SASL implementation (e.g., dovecot) >>> >>> 4. A deployment of said software implementation (e.g., >>> example.net) >>> >>> By "server" I think you mean a deployment. Correct? >>> >>> Rather than legislating in saslprepbis that all application >>> protocols shall leave casemapping up to implementations or >>> deployments, I think that it would be reasonable for the >>> specification of an application protocol using SASL (e.g., >>> draft-ietf-xmpp-6122bis) to recommend or require casemapping >>> behavior for all implementations or deployments of that >>> application protocol, or to leave such decisions up to the >>> implementation or deployment. For example, perhaps the XMPP spec >>> would say "all implementations shall perform case mapping, full >>> stop" whereas the IMAP spec might leave that up to >>> implementations or deployments. >> >> Here is what I suggest in Section 2.2 of >> draft-ietf-precis-saslprepbis: >> >> OLD 3. Uppercase and titlecase characters MUST be mapped to their >> lowercase equivalents. >> >> NEW 3. Uppercase and titlecase characters MAY be mapped to their >> lowercase equivalents. >> >> Then add the following sentence at the end of that section: >> >> Application protocols that use this profile MUST specify whether >> case mapping or additional mapping is to be applied by >> implementations or deployments of that protocol. > > I have a hard time thinking that, especially for credentials, app > protocol 1 chooses no mapping and app protocol 2 chooses mapping and > that both are using the SASL layer below. Looks like looking for > trouble here. no? I see your point, although I agree with Nico and Jeff that for SASL purposes these things will be mostly or completely determined by the mechanism (not all mechanisms have a concept of a "simple user name" -- the ones I'm familiar with are CRAM-MD5, DIGEST-MD5, and SCRAM). However, I think that this PRECIS profile might be used by non-SASL-using application protocols, such as HTTP authentication (see message from Yutaka Oiwa). I will try to formulate some corrected text. Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Thu Jul 11 12:46:03 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 3B10121F999C; Thu, 11 Jul 2013 12:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.548 X-Spam-Level: X-Spam-Status: No, score=-102.548 tagged_above=-999 required=5 tests=[AWL=0.051, 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 kG3LQBmIRrNx; Thu, 11 Jul 2013 12:45:58 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id B3DE621F992E; Thu, 11 Jul 2013 12:45:58 -0700 (PDT) Received: from sjc-vpn2-1401.cisco.com (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 8E9A141403; Thu, 11 Jul 2013 13:47:08 -0600 (MDT) Message-ID: <51DF0B74.5000808@stpeter.im> Date: Thu, 11 Jul 2013 13:45:56 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Marc Blanchet References: <20130328033951.21028.2480.idtracker@ietfa.amsl.com> <515E4D5B.5050102@stpeter.im> <51648B46.2020905@stpeter.im> <51D33084.5060903@stpeter.im> <51DDAF59.4040800@stpeter.im> <51DDC8D3.5060808@stpeter.im> <0DFFEBDE-F6FB-4C9E-BFBA-0181234C11A2@viagenie.ca> <51DF0735.8000006@stpeter.im> In-Reply-To: <51DF0735.8000006@stpeter.im> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: kitten@ietf.org, precis@ietf.org Subject: Re: [precis] [kitten] Fwd: I-D Action: draft-ietf-precis-saslprepbis-01.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, 11 Jul 2013 19:46:03 -0000 On 7/11/13 1:27 PM, Peter Saint-Andre wrote: > On 7/10/13 4:07 PM, Marc Blanchet wrote: >> Le 2013-07-10 à 16:49, Peter Saint-Andre a écrit >> : >> >>> Hi Nico, I've looked at this a bit further. Proposed text changes >>> below... >>> >>> On 7/10/13 1:00 PM, Peter Saint-Andre wrote: >>>> On 7/2/13 5:20 PM, Nico Williams wrote: >>>>> On Tue, Jul 2, 2013 at 2:56 PM, Peter Saint-Andre >>>>> wrote: >>>>>> On 5/3/13 1:39 PM, Nico Williams wrote: >>>>>> >>>>>>> Please forgive my apparent apathy. I lost track of this >>>>>>> due to business travel. >>>>>> >>>>>> And please forgive my delay in replying. It's good to know >>>>>> you're not apathetic. And as you can tell, we're proceeding >>>>>> rather slowly with this work. That doesn't mean it is >>>>>> unimportant. This recent example from the blogosphere might >>>>>> of interest: >>>>>> >>>>>> http://labs.spotify.com/2013/06/18/creative-usernames/ >>>>>> >>>>>> PRECIS might have helped those folks avoid some significant >>>>>> pain. >>>>>> >>>>>>> I'm not sure where the case mapping requirement for >>>>>>> usernames came from. >>>>>> >>>>>> Are you referring to global case mapping or local case >>>>>> mapping? >>>>>> >>>>>>> I guess it has something to do with the Turkish I and >>>>>>> such. >>>>>> >>>>>> Yes, that is a nasty problem with even nastier consequences: >>>>>> >>>>>> http://gizmodo.com/382026/a-cellphones-missing-dot-kills-two-people-puts-three-more-in-jail >>>>> >>>>> >>>>>> >>> >>>>>> > ! >>>>> >>>>> But that can't apply here. Or, if anything, case mappings >>>>> makes it more likely. Let's say I'm logged in in some app and >>>>> it shows the username I typed in, but because of case mapping >>>>> some typos are tolerated, so the username shown could offend >>>>> someone. Whereas if I'm required to type my username exactly >>>>> one way (not including NF) then that can't happen. So if >>>>> anything that link indicates we should not have case mappings >>>>> here... :) >>>>> >>>>>> Just to be clear, that's an issue of what we're calling >>>>>> local case mapping (where locale is taken into >>>>>> consideration). >>>>>> >>>>>>> I can't say I'm excited about this case mapping >>>>>>> requirement; if anything it strikes as silly. >>>>>> >>>>>> In general, the opinion so far has been that, say, StPeter >>>>>> is treated the same as stpeter when it comes to >>>>>> authentication and authorization based on usernames. Do you >>>>>> disagree? If so, why? For example, would you be inclined to >>>>>> leave this up to the protocol that uses SASL (say, IMAP or >>>>>> XMPP) instead of specifying it in SASLprepbis? >>>>> >>>>> I think it'd be nice if *servers* got to choose whether to do >>>>> this. The principle here is that the server should make right >>>>> when it comes to the username. This means that clients should >>>>> be pretty much able to send just about anything as a username >>>>> and let the server figure it out. >>>>> >>>>> Whether it's a server application or the mechanisms (or SASL >>>>> library) that applies such rules is a different story, and one >>>>> I don't think I care much about here. >>>> >>>> Ah, I see. >>>> >>>> It seems to me that there are numerous layers here: >>>> >>>> 1. SASL (including preparation and comparison rules) >>>> >>>> 2. The application protocol that's using SASL (e.g., IMAP) >>>> >>>> 3. A software implementation of the application protocol, which >>>> likely embeds or links to a SASL implementation (e.g., dovecot) >>>> >>>> 4. A deployment of said software implementation (e.g., >>>> example.net) >>>> >>>> By "server" I think you mean a deployment. Correct? >>>> >>>> Rather than legislating in saslprepbis that all application >>>> protocols shall leave casemapping up to implementations or >>>> deployments, I think that it would be reasonable for the >>>> specification of an application protocol using SASL (e.g., >>>> draft-ietf-xmpp-6122bis) to recommend or require casemapping >>>> behavior for all implementations or deployments of that >>>> application protocol, or to leave such decisions up to the >>>> implementation or deployment. For example, perhaps the XMPP spec >>>> would say "all implementations shall perform case mapping, full >>>> stop" whereas the IMAP spec might leave that up to >>>> implementations or deployments. >>> >>> Here is what I suggest in Section 2.2 of >>> draft-ietf-precis-saslprepbis: >>> >>> OLD 3. Uppercase and titlecase characters MUST be mapped to their >>> lowercase equivalents. >>> >>> NEW 3. Uppercase and titlecase characters MAY be mapped to their >>> lowercase equivalents. >>> >>> Then add the following sentence at the end of that section: >>> >>> Application protocols that use this profile MUST specify whether >>> case mapping or additional mapping is to be applied by >>> implementations or deployments of that protocol. >> >> I have a hard time thinking that, especially for credentials, app >> protocol 1 chooses no mapping and app protocol 2 chooses mapping and >> that both are using the SASL layer below. Looks like looking for >> trouble here. no? > > I see your point, although I agree with Nico and Jeff that for SASL > purposes these things will be mostly or completely determined by the > mechanism (not all mechanisms have a concept of a "simple user name" -- > the ones I'm familiar with are CRAM-MD5, DIGEST-MD5, and SCRAM). > However, I think that this PRECIS profile might be used by > non-SASL-using application protocols, such as HTTP authentication (see > message from Yutaka Oiwa). > > I will try to formulate some corrected text. How's this? OLD Application protocols that use this profile MUST specify whether case mapping or additional mapping is to be applied by implementations or deployments of that protocol. NEW SASL mechanisms and application protocols that directly re-use this profile MUST specify whether case mapping or additional mapping is to be applied by implementations or deployments thereof. Note that some application protocols themselves re-use SASL (examples include IMAP [RFC4616] and XMPP [RFC6120]); such protocols ought to apply the mapping rules defined for the relevant SASL mechanisms and not specify application-specific rules for that protocol's use of SASL or particular SASL mechanisms. Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Thu Jul 11 13:05:16 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 120B821F9D59; Thu, 11 Jul 2013 13:05:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 wUIkvDmjC7oc; Thu, 11 Jul 2013 13:05:11 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id CF61721F9D9D; Thu, 11 Jul 2013 13:05:10 -0700 (PDT) Received: from sjc-vpn2-1401.cisco.com (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 0B5D041403; Thu, 11 Jul 2013 14:05:52 -0600 (MDT) Message-ID: <51DF0FD8.3090908@stpeter.im> Date: Thu, 11 Jul 2013 14:04:40 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Jeffrey Hutzelman References: <20130328033951.21028.2480.idtracker@ietfa.amsl.com> <515E4D5B.5050102@stpeter.im> <51648B46.2020905@stpeter.im> <51D33084.5060903@stpeter.im> <51DDAF59.4040800@stpeter.im> <51DDC8D3.5060808@stpeter.im> <0DFFEBDE-F6FB-4C9E-BFBA-0181234C11A2@viagenie.ca> <14735_1373496114_r6AMfr0J008900_CAK3OfOijd2AvHgHd_Wi3+S=PZkTyUjRuRAXj5fV26ArsRO8zKg@mail.gmail.com> <1373554540.23328.87.camel@destiny.pc.cs.cmu.edu> In-Reply-To: <1373554540.23328.87.camel@destiny.pc.cs.cmu.edu> X-Enigmail-Version: 1.5.1 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: I-D Action: draft-ietf-precis-saslprepbis-01.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, 11 Jul 2013 20:05:16 -0000 On 7/11/13 8:55 AM, Jeffrey Hutzelman wrote: [snipping lots of interesting material, since I'm focused on finding appropriate text before the I-D deadline] > Now, back to the original point... > > >>>> Application protocols that use this profile MUST specify whether >> case >>>> mapping or additional mapping is to be applied by implementations >> or >>>> deployments of that protocol. >>> >>> I have a hard time thinking that, especially for credentials, app >> protocol 1 chooses no mapping and app protocol 2 chooses mapping and >> that both are using the SASL layer below. Looks like looking for >> trouble here. no? > > > The key phrase is "Application protocols that use this profile". Such a > protocol can apply the profile, and rules about whether to do > case-mapping, only to protocol elements that belong to it. For example, > an application might apply the profile to its SASL authorization names, > or to some other protocol element that is not related to SASL at all. > But it cannot apply the profile to protocol elements that a particular > SASL mechanism depends on, because those belong to the mechanism and > exist below the SASL abstraction, where the application protocol spec > cannot even see them. Agreed. > That said, I think we need to be clear that the profile is _also_ > available for use by SASL _mechanisms_, since after all, that was no > small part of the original purpose of SASLprep. The same requirement > applies -- a mechanism that uses the profile must specify whether to do > case folding. Right. We have two direct customers here: SASL mechanisms and application protocols that don't use SASL (e.g., HTTP auth). What you're terming "SASL application protocols" are indirect customers and IMHO we don't want to encourage them to do interesting things with the strings that they feed into SASL implementations. > FWIW, I think both the "OLD" and "NEW" variants from Peter's message are > wrong. We should not say that case-folding MUST be done, because that > mandates its use everywhere. However, we should also not say that it > MAY be done, because that looks like we are granting permission for > implementations of the profile to do case-folding anytime they want, > even if that's not what the protocol says. Mostly agree. The PRECIS framework specification says that any PRECIS "usage" (of which so far we have nickname, username, password, XMPP localpart, and XMPP resourcepart) must specify its rules for casemapping (among other things). > Instead, we should keep only the sentence Peter proposes adding at the > end, or some variation thereof, which has the effect of leaving the > case-folding question up to the protocol applying the profile. Right. So we need to re-word the rule: REALLY OLD 2. So-called additional mappings MAY be applied, such as those defined in [I-D.ietf-precis-mappings]. 3. Uppercase and titlecase characters MUST be mapped to their lowercase equivalents. MORE RECENT 2. So-called additional mappings MAY be applied, such as those defined in [I-D.ietf-precis-mappings]. 3. Uppercase and titlecase characters MAY be mapped to their lowercase equivalents. PROPOSED SOLUTION 2. SASL mechanisms and application protocols that directly use this profile MUST specify whether so-called additional mappings are to be applied, such as those defined in [I-D.ietf-precis-mappings]. 3. SASL mechanisms and application protocols that directly use this profile MUST specify whether uppercase and titlecase characters are be mapped to their lowercase equivalents. Then we'd have something like the follow-on paragraph I just posted: As noted, SASL mechanisms and application protocols that directly use this profile MUST specify whether case mapping and additional mappings are to be applied by implementations or deployments thereof. Note that some application protocols themselves re-use SASL (examples include IMAP [RFC4616] and XMPP [RFC6120]); such protocols ought to apply the mapping rules defined for the relevant SASL mechanisms and not specify application-specific rules for that protocol's use of SASL or particular SASL mechanisms. Peter -- Peter Saint-Andre https://stpeter.im/ From nico@cryptonector.com Thu Jul 11 13:13:17 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 F10FD21F9FF4; Thu, 11 Jul 2013 13:13:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.052 X-Spam-Level: X-Spam-Status: No, score=-2.052 tagged_above=-999 required=5 tests=[AWL=-0.075, 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 tppBgBQ6aAxN; Thu, 11 Jul 2013 13:13:12 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id C82B921F9FF9; Thu, 11 Jul 2013 13:13:11 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTP id 06920B807F; Thu, 11 Jul 2013 13:12:56 -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=SIDw9JWOdupHK5sigGWB e0I0nOA=; b=K9oVLbsha19NvtUUCIS4Z+MjrNVKA2cZXS527mWdFjXm7C9Ej1Jy HmpHNzWlfEBdClPqJh9t0Bhjzk58FW7NFrcIvHrEM5cj6sO1ps/zQq0juC7ZrpwN 2k8D+9dYOqawcmQbN2X9ti5pDPZnrILhFMI0f9mVAoR5Rj0HVxgdyn8= 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-a26.g.dreamhost.com (Postfix) with ESMTPSA id 4B5C7B8076; Thu, 11 Jul 2013 13:12:50 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id w59so7499519wes.10 for ; Thu, 11 Jul 2013 13:12:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XR56LBXPV+rHfkle4LLTPpthXtJ5JF579kswa1Tz3Ho=; b=NZfkp/JuTKbu8Y1ZIDGj8uMqVYundNFNuiXyDoyVA8vEAb7a3QGUefh1cfLi7cD1/B v5vNjIUBfdG+hLW6uXSbCElRqa/H8AcM5RwYPd9SBXK1URi2WdOfKUAFGPrbHVX9vz3s gduqkHHgbw6L8wZuUwo1sAt4pJkvL81R2dO9pvKeDva/WWu40LlzvAp+BcyXy4AKKzri cOBK+FR6PR4PtbDBCLP+tsFX+9fw0c6vwNuCCLKpovj/6bDRHvX+9CpKegw7D0zMXN/Z GL0a68FVGTYHD4P108YibBBkt8HM2xUU1mazdvaI5aMY5SXY5ouvPdQpHwRbDndbFofG xJfQ== MIME-Version: 1.0 X-Received: by 10.180.74.162 with SMTP id u2mr9516733wiv.36.1373573567834; Thu, 11 Jul 2013 13:12:47 -0700 (PDT) Received: by 10.217.38.138 with HTTP; Thu, 11 Jul 2013 13:12:47 -0700 (PDT) In-Reply-To: <51DF0B74.5000808@stpeter.im> References: <20130328033951.21028.2480.idtracker@ietfa.amsl.com> <515E4D5B.5050102@stpeter.im> <51648B46.2020905@stpeter.im> <51D33084.5060903@stpeter.im> <51DDAF59.4040800@stpeter.im> <51DDC8D3.5060808@stpeter.im> <0DFFEBDE-F6FB-4C9E-BFBA-0181234C11A2@viagenie.ca> <51DF0735.8000006@stpeter.im> <51DF0B74.5000808@stpeter.im> Date: Thu, 11 Jul 2013 15:12:47 -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: I-D Action: draft-ietf-precis-saslprepbis-01.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, 11 Jul 2013 20:13:17 -0000 On Thu, Jul 11, 2013 at 2:45 PM, Peter Saint-Andre wrote: > NEW > > SASL mechanisms and application protocols that directly re-use this > profile MUST specify whether case mapping or additional mapping is to > be applied by implementations or deployments thereof. Note that some > application protocols themselves re-use SASL (examples include IMAP > [RFC4616] and XMPP [RFC6120]); such protocols ought to apply the > mapping rules defined for the relevant SASL mechanisms and not > specify application-specific rules for that protocol's use of SASL or > particular SASL mechanisms. I don't really like the second sentence. In all cases *only* the application applies any stringprep to authorization IDs, and *only* mechanisms apply any stringprep to authentication IDs. (If a SASL framework implementation allows an app to provide an authentication DB for a mechanism then the app is providing a bit of mechanism functionality but it should still be understood as properly a part of the mechanism. We don't usually go into that level of detail in the core SASL RFC, and we shouldn't here. NEW SASL mechanisms that directly re-use this profile MUST specify whether case mapping is to be applied to authentication IDs, and when. 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. SASL application protocols that directly re-use this profile MUST specify whether case mapping is to be applied to authorization IDs. SASL application protocols SHOULD delay any case mapping of authorization IDs to the last possible moment, which happens to necessarily be on the server side. Note that, in keeping with RFC4422, SASL applications must not apply this or any other profile to authentication IDs. Note that, in keeping with RFC4422, SASL mechanisms must not apply this or any other profile to authorization IDs. Nico -- From stpeter@stpeter.im Thu Jul 11 13:28: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 AA0E011E8122; Thu, 11 Jul 2013 13:28:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.551 X-Spam-Level: X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[AWL=0.048, 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 zXeK6Vc8gq2Y; Thu, 11 Jul 2013 13:27:55 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF8C21F995A; Thu, 11 Jul 2013 13:27:38 -0700 (PDT) Received: from sjc-vpn2-1401.cisco.com (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9205341403; Thu, 11 Jul 2013 14:28:32 -0600 (MDT) Message-ID: <51DF1527.6080102@stpeter.im> Date: Thu, 11 Jul 2013 14:27:19 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Nico Williams References: <20130328033951.21028.2480.idtracker@ietfa.amsl.com> <515E4D5B.5050102@stpeter.im> <51648B46.2020905@stpeter.im> <51D33084.5060903@stpeter.im> <51DDAF59.4040800@stpeter.im> <51DDC8D3.5060808@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org, precis@ietf.org Subject: Re: [precis] [kitten] Fwd: I-D Action: draft-ietf-precis-saslprepbis-01.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, 11 Jul 2013 20:28:00 -0000 On 7/10/13 4:37 PM, Nico Williams wrote: > On Wed, Jul 10, 2013 at 3:49 PM, Peter Saint-Andre wrote: >> Here is what I suggest in Section 2.2 of draft-ietf-precis-saslprepbis: >> >> OLD >> 3. Uppercase and titlecase characters MUST be mapped to their >> lowercase equivalents. >> >> NEW >> 3. Uppercase and titlecase characters MAY be mapped to their >> lowercase equivalents. > > Do we need to give advice regarding the use of query strings for > cryptographic protocols? E.g., usernames as salts. I think we do. It seems to me that rules for handling query strings in a cryptographic protocol would be the responsibility of that protocol. Now, maybe you are suggesting that such protocols would apply the PRECIS profile we're defining here, if it provides what they need. Do you think that the rules in draft-ietf-precis-saslprepbis are sufficient? I get the sense you think more is needed, but I'm not yet sure exactly what. > Specifically, *mechanisms* must specify what normalizations (and let's > provide a nice one for them to all use) for such purposes. When you say "mechanisms" do you mean "SASL mechanisms" and when you say "normalizations" do you mean "Unicode normalization forms"? I ask because I think we have those bases covered, but perhaps you're looking for more... Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Thu Jul 11 13:30:28 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 17BA211E815B; Thu, 11 Jul 2013 13:30:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.552 X-Spam-Level: X-Spam-Status: No, score=-102.552 tagged_above=-999 required=5 tests=[AWL=0.047, 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 sHfamRjcu6jJ; Thu, 11 Jul 2013 13:30:23 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id DC4C611E8122; Thu, 11 Jul 2013 13:30:22 -0700 (PDT) Received: from sjc-vpn2-1401.cisco.com (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 8DC4341403; Thu, 11 Jul 2013 14:31:32 -0600 (MDT) Message-ID: <51DF15DB.1010200@stpeter.im> Date: Thu, 11 Jul 2013 14:30:19 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Nico Williams References: <20130328033951.21028.2480.idtracker@ietfa.amsl.com> <515E4D5B.5050102@stpeter.im> <51648B46.2020905@stpeter.im> <51D33084.5060903@stpeter.im> <51DDAF59.4040800@stpeter.im> <51DDC8D3.5060808@stpeter.im> <0DFFEBDE-F6FB-4C9E-BFBA-0181234C11A2@viagenie.ca> <51DF0735.8000006@stpeter.im> <51DF0B74.5000808@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org, precis@ietf.org Subject: Re: [precis] [kitten] Fwd: I-D Action: draft-ietf-precis-saslprepbis-01.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, 11 Jul 2013 20:30:28 -0000 On 7/11/13 2:12 PM, Nico Williams wrote: > On Thu, Jul 11, 2013 at 2:45 PM, Peter Saint-Andre wrote: >> NEW >> >> SASL mechanisms and application protocols that directly re-use this >> profile MUST specify whether case mapping or additional mapping is to >> be applied by implementations or deployments thereof. Note that some >> application protocols themselves re-use SASL (examples include IMAP >> [RFC4616] and XMPP [RFC6120]); such protocols ought to apply the >> mapping rules defined for the relevant SASL mechanisms and not >> specify application-specific rules for that protocol's use of SASL or >> particular SASL mechanisms. > > I don't really like the second sentence. In all cases *only* the > application applies any stringprep to authorization IDs, and *only* > mechanisms apply any stringprep to authentication IDs. (If a SASL > framework implementation allows an app to provide an authentication DB > for a mechanism then the app is providing a bit of mechanism > functionality but it should still be understood as properly a part of > the mechanism. We don't usually go into that level of detail in the > core SASL RFC, and we shouldn't here. > > NEW > SASL mechanisms that directly re-use this profile MUST specify > whether case mapping is to be applied to authentication IDs, and > when. 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. > > SASL application protocols that directly re-use this profile MUST > specify whether case mapping is to be applied to authorization IDs. > SASL application protocols SHOULD delay any case mapping of > authorization IDs to the last possible moment, which happens to > necessarily be on the server side. > > Note that, in keeping with RFC4422, SASL applications must not apply > this or any other profile to authentication IDs. > > Note that, in keeping with RFC4422, SASL mechanisms must not apply > this or any other profile to authorization IDs. That is much more precise than what I had sketched out, and it looks good to me. Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Thu Jul 11 16:32:38 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 9D41C11E81CD; Thu, 11 Jul 2013 16:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.384 X-Spam-Level: X-Spam-Status: No, score=-102.384 tagged_above=-999 required=5 tests=[AWL=0.215, 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 e+bsKwVvfC7u; Thu, 11 Jul 2013 16:32:33 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 87D4311E81BB; Thu, 11 Jul 2013 16:32:33 -0700 (PDT) Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D4FD54134B; Thu, 11 Jul 2013 17:33:42 -0600 (MDT) Message-ID: <51DF408E.6010201@stpeter.im> Date: Thu, 11 Jul 2013 17:32:30 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Jeffrey Hutzelman References: <20130328033951.21028.2480.idtracker@ietfa.amsl.com> <515E4D5B.5050102@stpeter.im> <51648B46.2020905@stpeter.im> <51D33084.5060903@stpeter.im> <51DDAF59.4040800@stpeter.im> <51DDC8D3.5060808@stpeter.im> <0DFFEBDE-F6FB-4C9E-BFBA-0181234C11A2@viagenie.ca> <51DF0735.8000006@stpeter.im> <51DF0B74.5000808@stpeter.im> <29306_1373574631_r6BKUU21031820_51DF15DB.1010200@stpeter.im> <1373575553.23365.268.camel@minbar.fac.cs.cmu.edu> In-Reply-To: <1373575553.23365.268.camel@minbar.fac.cs.cmu.edu> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org, Nico Williams , precis@ietf.org Subject: Re: [precis] [kitten] Fwd: I-D Action: draft-ietf-precis-saslprepbis-01.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, 11 Jul 2013 23:32:38 -0000 On 7/11/13 2:45 PM, Jeffrey Hutzelman wrote: > On Thu, 2013-07-11 at 14:30 -0600, Peter Saint-Andre wrote: > >>> NEW >>> SASL mechanisms that directly re-use this profile MUST specify >>> whether case mapping is to be applied to authentication IDs, and >>> when. 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. >>> >>> SASL application protocols that directly re-use this profile MUST >>> specify whether case mapping is to be applied to authorization IDs. >>> SASL application protocols SHOULD delay any case mapping of >>> authorization IDs to the last possible moment, which happens to >>> necessarily be on the server side. >>> >>> Note that, in keeping with RFC4422, SASL applications must not apply >>> this or any other profile to authentication IDs. >>> >>> Note that, in keeping with RFC4422, SASL mechanisms must not apply >>> this or any other profile to authorization IDs. >> >> That is much more precise than what I had sketched out, and it looks >> good to me. > > Me too Great. If there are no objections from my co-author in the next 24 hours or so, I'll submit a revised I-D. I'd really like to finish off all this i18n stuff... :-) Peter -- Peter Saint-Andre https://stpeter.im/ From jhutz@cmu.edu Thu Jul 11 07:56: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 A343E21F9C22; Thu, 11 Jul 2013 07:56:06 -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 gWlFxUaES4fG; Thu, 11 Jul 2013 07:55:52 -0700 (PDT) Received: from smtp03.srv.cs.cmu.edu (SMTP03.SRV.CS.CMU.EDU [128.2.217.198]) by ietfa.amsl.com (Postfix) with ESMTP id 7965F21F9BD0; Thu, 11 Jul 2013 07:55:51 -0700 (PDT) Received: from [192.168.202.142] (pool-74-111-100-191.pitbpa.fios.verizon.net [74.111.100.191]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id r6BEteXQ020249 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 11 Jul 2013 10:55:41 -0400 (EDT) Message-ID: <1373554540.23328.87.camel@destiny.pc.cs.cmu.edu> From: Jeffrey Hutzelman To: Nico Williams Date: Thu, 11 Jul 2013 10:55:40 -0400 In-Reply-To: <14735_1373496114_r6AMfr0J008900_CAK3OfOijd2AvHgHd_Wi3+S=PZkTyUjRuRAXj5fV26ArsRO8zKg@mail.gmail.com> References: <20130328033951.21028.2480.idtracker@ietfa.amsl.com> <515E4D5B.5050102@stpeter.im> <51648B46.2020905@stpeter.im> <51D33084.5060903@stpeter.im> <51DDAF59.4040800@stpeter.im> <51DDC8D3.5060808@stpeter.im> <0DFFEBDE-F6FB-4C9E-BFBA-0181234C11A2@viagenie.ca> <14735_1373496114_r6AMfr0J008900_CAK3OfOijd2AvHgHd_Wi3+S=PZkTyUjRuRAXj5fV26ArsRO8zKg@mail.gmail.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.6.2-0ubuntu0.1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: mimedefang-cmuscs on 128.2.217.198 X-Mailman-Approved-At: Thu, 11 Jul 2013 18:13:21 -0700 Cc: kitten@ietf.org, precis@ietf.org, jhutz@cmu.edu Subject: Re: [precis] [kitten] Fwd: I-D Action: draft-ietf-precis-saslprepbis-01.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, 11 Jul 2013 14:56:07 -0000 On Wed, 2013-07-10 at 17:41 -0500, Nico Williams wrote: > The app protocol could specify whether the client does or does not > have to, I don't mind that. But it'd be silly to specify something > that conflicts with whatever the mechanism will apply, so, that's a > good point. > > All the more reason to have the app do nothing with usernames. Just > pass them to the mechanism. Let the mechanism work it out. This is a key point. SASL doesn't have usernames. It has authentication names and authorization names. SASL application protocols do not get a say in how authentication names are handled, period. It's just not up to them; these names are artifacts of the SASL mechanism, and their handling is generally dictated by the underlying authentication technology. SASLprep is not and never was about setting down general rules for handling authentication names or what SASL application protocols must do. It was about providing a profile for use by specific SASL mechanisms that are in the position of defining "username" or password elements that need one. Applications do get a say about authorization names; in fact, they get the _only_ say. They are the application's "usernames", and SASL doesn't get to say what they look like or what they mean. That is the purview of the application, which is entirely responsible for authorization. SASL is merely the authentication framework, and not necessarily even the only one supported by any given application. Of course, we can give advice to application protocol designers, but we can't effectively impose requirements, and there's not really even any reason to do so. Further, any advice we do give would not be in any way SASL-specific, so while it might be appropriate for PRECIS to do such a thing, saslprep might not be the best place to do so. > The mechanism on the client side should only normalize usernames for > the purposes of generating salts. This is almost right. From what I've seen, in authentication, filesystems, and other places, the right thing is almost always to apply normalization or any other canonicalizations at the last possible moment, and no later. For example, if you're going to look up a name in a database, normalize just before the lookup and not before. Or, better yet, don't normalize keys that go into the database, and do normalization-insensitive comparison instead. This can be a bit tricky depending on the nature of the database, but not impossible. The case you mention is an interesting one, though stated slightly too narrowly. Any string that is going to be used as a salt, or to derive keying material, or as input to a cryptographic hash, will need to be normalized before doing that. But, _only if the string itself will not be sent_. If the string is being sent, then send and use the un-normalized form, and the far end can use a normalization-insensitive comparison to decide if it got what it was expecting, or it can normalize (as late as possible!) and do whatever database lookup is needed. Note again that there is nothing about this advice that's specific to SASL or SASL mechanisms or SASL application protocols. However, it does apply to protocol designs, not implementations -- if a protocol says to normalize at a particular point, an implementation cannot decide to instead follow the "as late as possible" rule, or interoperability will suffer. I think that means we need to be careful about anything we specify here; we can offer advice to protocol designers, but we cannot impose requirements directly on implementations about whether or when to normalize or case-convert. Otherwise, we risk hindering interoperability instead of helping it. Now, back to the original point... > >> Application protocols that use this profile MUST specify whether > case > >> mapping or additional mapping is to be applied by implementations > or > >> deployments of that protocol. > > > > I have a hard time thinking that, especially for credentials, app > protocol 1 chooses no mapping and app protocol 2 chooses mapping and > that both are using the SASL layer below. Looks like looking for > trouble here. no? The key phrase is "Application protocols that use this profile". Such a protocol can apply the profile, and rules about whether to do case-mapping, only to protocol elements that belong to it. For example, an application might apply the profile to its SASL authorization names, or to some other protocol element that is not related to SASL at all. But it cannot apply the profile to protocol elements that a particular SASL mechanism depends on, because those belong to the mechanism and exist below the SASL abstraction, where the application protocol spec cannot even see them. That said, I think we need to be clear that the profile is _also_ available for use by SASL _mechanisms_, since after all, that was no small part of the original purpose of SASLprep. The same requirement applies -- a mechanism that uses the profile must specify whether to do case folding. FWIW, I think both the "OLD" and "NEW" variants from Peter's message are wrong. We should not say that case-folding MUST be done, because that mandates its use everywhere. However, we should also not say that it MAY be done, because that looks like we are granting permission for implementations of the profile to do case-folding anytime they want, even if that's not what the protocol says. Instead, we should keep only the sentence Peter proposes adding at the end, or some variation thereof, which has the effect of leaving the case-folding question up to the protocol applying the profile. -- Jeff From jhutz@cmu.edu Thu Jul 11 13:46: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 C30E721F9DA8; Thu, 11 Jul 2013 13:46:11 -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 Li9vk5fASbWy; Thu, 11 Jul 2013 13:46:05 -0700 (PDT) Received: from smtp01.srv.cs.cmu.edu (SMTP01.SRV.CS.CMU.EDU [128.2.217.196]) by ietfa.amsl.com (Postfix) with ESMTP id B8AD921F9D91; Thu, 11 Jul 2013 13:46:05 -0700 (PDT) Received: from [128.2.193.239] (minbar.fac.cs.cmu.edu [128.2.193.239]) (authenticated bits=0) by smtp01.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id r6BKjrs3026278 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 11 Jul 2013 16:45:53 -0400 (EDT) Message-ID: <1373575553.23365.268.camel@minbar.fac.cs.cmu.edu> From: Jeffrey Hutzelman To: Peter Saint-Andre Date: Thu, 11 Jul 2013 16:45:53 -0400 In-Reply-To: <29306_1373574631_r6BKUU21031820_51DF15DB.1010200@stpeter.im> References: <20130328033951.21028.2480.idtracker@ietfa.amsl.com> <515E4D5B.5050102@stpeter.im> <51648B46.2020905@stpeter.im> <51D33084.5060903@stpeter.im> <51DDAF59.4040800@stpeter.im> <51DDC8D3.5060808@stpeter.im> <0DFFEBDE-F6FB-4C9E-BFBA-0181234C11A2@viagenie.ca> <51DF0735.8000006@stpeter.im> <51DF0B74.5000808@stpeter.im> <29306_1373574631_r6BKUU21031820_51DF15DB.1010200@stpeter.im> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Scanned-By: mimedefang-cmuscs on 128.2.217.196 X-Mailman-Approved-At: Thu, 11 Jul 2013 18:13:21 -0700 Cc: kitten@ietf.org, Nico Williams , precis@ietf.org, jhutz@cmu.edu Subject: Re: [precis] [kitten] Fwd: I-D Action: draft-ietf-precis-saslprepbis-01.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, 11 Jul 2013 20:46:11 -0000 On Thu, 2013-07-11 at 14:30 -0600, Peter Saint-Andre wrote: > > NEW > > SASL mechanisms that directly re-use this profile MUST specify > > whether case mapping is to be applied to authentication IDs, and > > when. 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. > > > > SASL application protocols that directly re-use this profile MUST > > specify whether case mapping is to be applied to authorization IDs. > > SASL application protocols SHOULD delay any case mapping of > > authorization IDs to the last possible moment, which happens to > > necessarily be on the server side. > > > > Note that, in keeping with RFC4422, SASL applications must not apply > > this or any other profile to authentication IDs. > > > > Note that, in keeping with RFC4422, SASL mechanisms must not apply > > this or any other profile to authorization IDs. > > That is much more precise than what I had sketched out, and it looks > good to me. Me too From internet-drafts@ietf.org Fri Jul 12 11:38: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 0DB2211E816D; Fri, 12 Jul 2013 11:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 eLhOMrra48Vm; Fri, 12 Jul 2013 11:38:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 96CF911E815E; Fri, 12 Jul 2013 11:38:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130712183810.12543.75451.idtracker@ietfa.amsl.com> Date: Fri, 12 Jul 2013 11:38:10 -0700 Cc: precis@ietf.org Subject: [precis] I-D Action: draft-ietf-precis-saslprepbis-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: Fri, 12 Jul 2013 18:38:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Preparation and Comparison of Internation= alized Strings Working Group of the IETF. Title : Preparation and Comparison of Internationalized Strings = Representing Simple User Names and Passwords Author(s) : Peter Saint-Andre Alexey Melnikov Filename : draft-ietf-precis-saslprepbis-03.txt Pages : 14 Date : 2013-07-12 Abstract: This document describes how to handle Unicode strings representing simple user names and passwords, primarily for purposes of comparison. This profile is intended to be used by Simple Authentication and Security Layer (SASL) mechanisms (such as PLAIN and SCRAM-SHA-1), as well as other protocols that exchange simple user names or 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-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-precis-saslprepbis-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From marc.blanchet@viagenie.ca Sun Jul 14 09:31:23 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 41E7121F944C; Sun, 14 Jul 2013 09:31:23 -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 oLxL7GEdCyJB; Sun, 14 Jul 2013 09:31:22 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8ABD821F93C4; Sun, 14 Jul 2013 09:31:22 -0700 (PDT) Received: from h195.viagenie.ca (h195.viagenie.ca [206.123.31.195]) by jazz.viagenie.ca (Postfix) with ESMTPSA id DD846403FF; Sun, 14 Jul 2013 12:31:21 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Marc Blanchet In-Reply-To: <51DF408E.6010201@stpeter.im> Date: Sun, 14 Jul 2013 12:31:21 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <58D2B0A9-9A5E-47E7-A551-9814E9033FCA@viagenie.ca> References: <20130328033951.21028.2480.idtracker@ietfa.amsl.com> <515E4D5B.5050102@stpeter.im> <51648B46.2020905@stpeter.im> <51D33084.5060903@stpeter.im> <51DDAF59.4040800@stpeter.im> <51DDC8D3.5060808@stpeter.im> <0DFFEBDE-F6FB-4C9E-BFBA-0181234C11A2@viagenie.ca> <51DF0735.8000006@stpeter.im> <51DF0B74.5000808@stpeter.im> <29306_1373574631_r6BKUU21031820_51DF15DB.1010200@stpeter.im> <1373575553.23365.268.camel@minbar.fac.cs.cmu.edu> <51DF408E.6010201@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1508) Cc: kitten@ietf.org, Nico Williams , precis@ietf.org, Jeffrey Hutzelman Subject: Re: [precis] [kitten] Fwd: I-D Action: draft-ietf-precis-saslprepbis-01.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, 14 Jul 2013 16:31:23 -0000 Le 2013-07-11 =E0 19:32, Peter Saint-Andre a =E9crit = : > On 7/11/13 2:45 PM, Jeffrey Hutzelman wrote: >> On Thu, 2013-07-11 at 14:30 -0600, Peter Saint-Andre wrote: >>=20 >>>> NEW >>>> SASL mechanisms that directly re-use this profile MUST specify >>>> whether case mapping is to be applied to authentication IDs, and >>>> when. 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. >>>>=20 >>>> SASL application protocols that directly re-use this profile MUST >>>> specify whether case mapping is to be applied to authorization = IDs. >>>> SASL application protocols SHOULD delay any case mapping of >>>> authorization IDs to the last possible moment, which happens to >>>> necessarily be on the server side. >>>>=20 >>>> Note that, in keeping with RFC4422, SASL applications must not = apply >>>> this or any other profile to authentication IDs. >>>>=20 >>>> Note that, in keeping with RFC4422, SASL mechanisms must not = apply >>>> this or any other profile to authorization IDs. >>>=20 >>> That is much more precise than what I had sketched out, and it looks >>> good to me. >>=20 >> Me too >=20 > Great. If there are no objections from my co-author in the next 24 = hours > or so, you're ok ... ;-) Marc. > I'll submit a revised I-D. I'd really like to finish off all this > i18n stuff... :-) >=20 > Peter >=20 > --=20 > Peter Saint-Andre > https://stpeter.im/ From yoshiro.yoneya@jprs.co.jp Mon Jul 22 00:12:44 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 CE51811E80E0 for ; Mon, 22 Jul 2013 00:12:44 -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 OEpmV4a5F6P9 for ; Mon, 22 Jul 2013 00:12:44 -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 0C04B11E80DC for ; Mon, 22 Jul 2013 00:12:43 -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 r6M7CdEq030418 for ; Mon, 22 Jul 2013 16:12:41 +0900 X-AuditID: ac120820-b7f306d00000490a-96-51ecdb68edc7 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 0F.D9.18698.86BDCE15; Mon, 22 Jul 2013 16:12:40 +0900 (JST) Date: Mon, 22 Jul 2013 16:12:37 +0900 From: Yoshiro YONEYA To: precis@ietf.org Message-Id: <20130722161237.b36f0e401e077c8767ac9482@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+NgFlrKIsWRmVeSWpSXmKPExsWyRoiFTzfj9ptAg3VLjSx2ff/D6sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujH3frrMWTGKvWNhzjr2B8QFrFyMHh4SAicT5e6FdjJxAppjE hXvr2boYuTiEBI4zSqzcv54JJMEioCrxvnUPC4jNJmAg8WvZb7C4iICwxK3bC1lBbGEBZYk9 e+6wgdi8Ag4SF6f2MkEMtZC40NTBDrKLV0BQ4u8OYZAws4CWxMNft1ggbHmJ7W/nME9g5JmF UDULSdUsJFULGJlXMcrkp6XpFqfmpRTnphsY6pVU5utlFRQV6yWD6E2M4FDhUNjBOOOUwSFG AQ5GJR7eZ0FvAoVYE8uKK3MPMUpyMCmJ8nbdAArxJeWnVGYkFmfEF5XmpBYfYpTgYFYS4fVc BZTjTUmsrEotyodJSXOwKInzHv9zJlBIID2xJDU7NbUgtQgmK8PBoSTB+/4mUKNgUWp6akVa Zk4JQpqJgxNkOA/Q8KsgNbzFBYm5xZnpEPlTjJJS4rwfQRICIImM0jy43leM4kAvCPNeBMny AOMerusV0EAmoIGGra9BBpYkIqSkGhhTnP+4bji45EvqWmkZkeSaafLnxDXbEtYn2mVLtcv9 P15e4hWXmW1w7NP1b0KeZfMZDvYUyyxK9WrxW5+ywkU7soXp0u0ojdQ84dtT6l0jpFem+Xp1 7Vbanvxw+08B94v2Uu3G3r+U7k7Zs979ue0DlTfsor0/t9SXXzjId3he47WmdVsWzlBiKc5I NNRiLipOBADbNbSZuAIAAA== Subject: [precis] IETF87 Berlin draft agenda 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, 22 Jul 2013 07:12:45 -0000 Dear all, Following is draft agenda for IETF 87 Berlin. Please send comments/additions/changes to the chairs. 1. Administrativia 2. Document updates / Discussion 2.1 WG I-Ds (1) Framework https://datatracker.ietf.org/doc/draft-ietf-precis-framework/ (2) Preparation and Comparison of Nicknames https://datatracker.ietf.org/doc/draft-ietf-precis-nickname/ (3) Mapping characters for precis classes http://datatracker.ietf.org/doc/draft-ietf-precis-mappings/ (4) Preparation and Comparison of Internationalized Strings Representing Simple User Names and Passwords http://datatracker.ietf.org/doc/draft-ietf-precis-saslprepbis/ 2.2 Individual Documents (1) HTTPAuthPrep: PRECIS profile for HTTP Authentication https://datatracker.ietf.org/doc/draft-oiwa-precis-httpauthprep/ 3. Next steps Marc & Yoneya, co-chairs From stpeter@stpeter.im Mon Jul 22 19:49: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 7F07A11E8183 for ; Mon, 22 Jul 2013 19:49:51 -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 trCVV+XjbtvZ for ; Mon, 22 Jul 2013 19:49:47 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 9D5A811E81D6 for ; Mon, 22 Jul 2013 19:49:46 -0700 (PDT) Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 8F82041189; Mon, 22 Jul 2013 20:51:33 -0600 (MDT) Message-ID: <51EDEF48.6040705@stpeter.im> Date: Mon, 22 Jul 2013 20:49:44 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Yoshiro YONEYA References: <20130722161237.b36f0e401e077c8767ac9482@jprs.co.jp> In-Reply-To: <20130722161237.b36f0e401e077c8767ac9482@jprs.co.jp> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: precis@ietf.org Subject: Re: [precis] IETF87 Berlin draft agenda 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, 23 Jul 2013 02:49:51 -0000 Thanks for the draft agenda. A bit of feedback inline... On 7/22/13 1:12 AM, Yoshiro YONEYA wrote: > Dear all, > > Following is draft agenda for IETF 87 Berlin. > Please send comments/additions/changes to the chairs. > > 1. Administrativia > > 2. Document updates / Discussion > 2.1 WG I-Ds > (1) Framework > https://datatracker.ietf.org/doc/draft-ietf-precis-framework/ I can give an update on that spec and ask if people disagree with the (IMHO relatively small) changes between -08 and -09. > (2) Preparation and Comparison of Nicknames > https://datatracker.ietf.org/doc/draft-ietf-precis-nickname/ As far as I know, this is done -- we completed WGLC last year and it needs to undergo IETF Last Call. > (3) Mapping characters for precis classes > http://datatracker.ietf.org/doc/draft-ietf-precis-mappings/ > > (4) Preparation and Comparison of Internationalized Strings Representing > Simple User Names and Passwords > http://datatracker.ietf.org/doc/draft-ietf-precis-saslprepbis/ > > 2.2 Individual Documents > (1) HTTPAuthPrep: PRECIS profile for HTTP Authentication > https://datatracker.ietf.org/doc/draft-oiwa-precis-httpauthprep/ As I mentioned on the list, I think that we don't need an httpauthprep profile, since saslprepbis probably solves the problem for HTTP auth. But that would be a useful discussion to have in person. Peter -- Peter Saint-Andre https://stpeter.im/ From y.oiwa@aist.go.jp Mon Jul 22 20:58:24 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 C6B3A11E81D7 for ; Mon, 22 Jul 2013 20:58:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 TSefXpPn1ipi for ; Mon, 22 Jul 2013 20:58:20 -0700 (PDT) Received: from na3sys010aog114.obsmtp.com (na3sys010aog114.obsmtp.com [74.125.245.96]) by ietfa.amsl.com (Postfix) with ESMTP id 388DF11E8183 for ; Mon, 22 Jul 2013 20:58:19 -0700 (PDT) Received: from mail-vc0-f171.google.com ([209.85.220.171]) (using TLSv1) by na3sys010aob114.postini.com ([74.125.244.12]) with SMTP ID DSNKUe3/WnxEcHkVhdACE6PbUCAIhxhDH3GK@postini.com; Mon, 22 Jul 2013 20:58:20 PDT Received: by mail-vc0-f171.google.com with SMTP id ij15so828638vcb.16 for ; Mon, 22 Jul 2013 20:58:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=JRZDC3ZFMdFAwTNMABFIlQZRl/O10GQmQ8rRO0MMQRM=; b=A/xTZmNlekN4lXhYsguL+cgRAR06fZHZEMXLWfg2ufM69cybi2VN0ReE31Pkh403h5 LsxdY4MSEf7ehTNOXSp/h2Hbu7OHgpKK/B9iDRWvD/k2dLEV9b7j85Gg/BFWIhq0dmP3 E3JpJeBa7jFcFDueYZJW7bC9rkXXgnwE5qH6A= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=JRZDC3ZFMdFAwTNMABFIlQZRl/O10GQmQ8rRO0MMQRM=; b=AFZYP4JQ5hmjnYXViu2Df1EATo+lon0xYNHGdTyBI6APgr1xHl3cLRQxxqgWtohfpB x1vIE4pB1E8pNdEci2X7v9lQ0ND7zETpoXUbLETWS5r1kKgdiiPORDOsuGb5aOP3OtG6 k2dexb/YwIMVw+NcLAJ2jMWVcQyDipHB3/+mSZPMKy+mLmV4lEDQ4HheEbY9HSd5Rn6O G1CuWWlSesNO9djFNKBFrvr4EQSoenXMtAMudRPE1QlagQzWutsmPsxBviWthZ1tcZi4 Kq7AvLtjndW3BCY2l7yslpy2e7tupoSP4JP2FPD/89AQN7WSNyxZ5b4PNtiXQK4I09gR 3ksQ== X-Received: by 10.221.31.130 with SMTP id sg2mr10021242vcb.86.1374551897972; Mon, 22 Jul 2013 20:58:17 -0700 (PDT) X-Received: by 10.221.31.130 with SMTP id sg2mr10021238vcb.86.1374551897862; Mon, 22 Jul 2013 20:58:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.230.101 with HTTP; Mon, 22 Jul 2013 20:57:57 -0700 (PDT) In-Reply-To: <51EDEF48.6040705@stpeter.im> References: <20130722161237.b36f0e401e077c8767ac9482@jprs.co.jp> <51EDEF48.6040705@stpeter.im> From: Yutaka OIWA Date: Tue, 23 Jul 2013 12:57:57 +0900 Message-ID: To: Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmHyOxtqSn0Uy/7oP9JxJMfQFwC41WwisH1ljI1vRwT3GQsjuMwJ1k9BkNWLpbVJdfm3lPHiySIii0e2QXSs1gl6aGqTSVEPjRIYF/dNX3o1zLfX9E54fY9ep14MpK4+1FxOr11cJB2CxvnRcvHqmswMJai2w== Cc: precis@ietf.org Subject: Re: [precis] IETF87 Berlin draft agenda 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, 23 Jul 2013 03:58:24 -0000 Dear Peter, 2013/7/23 Peter Saint-Andre : >> 2.2 Individual Documents >> (1) HTTPAuthPrep: PRECIS profile for HTTP Authentication >> https://datatracker.ietf.org/doc/draft-oiwa-precis-httpauthprep/ > > As I mentioned on the list, I think that we don't need an httpauthprep > profile, since saslprepbis probably solves the problem for HTTP auth. > But that would be a useful discussion to have in person. I agreed that there should be a unified profile for simple HTTP/Web related preparation in hand, however, at the same time, I think that application of precis framework for HTTP authentication still need some special mentions/discussions. That part is apart from the precis-based translation rules itself. I do not know what type of document (Standard Track/Informational), which group (precis/httpauth/httpbis/appsopen/whatever) will be appropriate, so at this time I'm going to describe in precis what we thought on writing httpauth, and hoping to get a straight discussions and suggestions how these rest things are to be arranged well. -- Yutaka OIWA, Ph.D. Leader, System Life-cycle Research Group Research Institute for Secure Systems (RISEC) National Institute of Advanced Industrial Science and Technology (AIST) Mail addresses: , OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B5] From stpeter@stpeter.im Tue Jul 23 09:26:45 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 4739511E82EC for ; Tue, 23 Jul 2013 09:26:45 -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 3ufx5z8b6B9g for ; Tue, 23 Jul 2013 09:26:40 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 30EC811E82DF for ; Tue, 23 Jul 2013 09:26:26 -0700 (PDT) Received: from sjc-vpn6-1242.cisco.com (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 8F62441189; Tue, 23 Jul 2013 10:28:09 -0600 (MDT) Message-ID: <51EEAEAA.9090408@stpeter.im> Date: Tue, 23 Jul 2013 10:26:18 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "precis@ietf.org" X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [precis] draft slides for framework and username 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, 23 Jul 2013 16:26:45 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Here are draft slides for my two presentations at IEFF 87 in Berlin: https://stpeter.im/files/ietf87-precis-framework.pdf https://stpeter.im/files/ietf87-precis-username.pdf Feedback is welcome. 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/ iQIcBAEBAgAGBQJR7q6qAAoJEOoGpJErxa2pMHQP/RsM8FcPQaB3fp7B6UbakFVF f1HGBHgmw/dq/rKkcyh0k5nxsFx+8jnR9j4W1FafjMK9T1UX3h/PUcSxZ26P1voe kNvShAYLflCv6CLgjO1UpAcCEPKc8wFPZMDcoEz2MkY+uC2hx+jVNrh+NrBXoZQC f8alF6RMcnCco+wthu64epb0pn57Z7HneiElKx1Yajqg/2rd8CZoWCOetXvd2b1Q 0yKi+dJsEJSbH+IAW+fLDFgquGnd2M+cdkmeUWGJP1d5jNzQZR9PWWKo81XD0Q7W F7v4FFcfgTGN/b8+HG3wXyJoFVORNh+TqsgyIQohWjo6zXfr8lpB4bPh9mAaELra fkzHsGzDtgb28T/r6sssDB01wXBvpO9COM7f9hH7nOzsnZUj0D5lXquyk2dJV0on udJ43lAsJl/b88Ep5H/pSnAoJY0DRQ9fj9/MmPw01CikxobvD6xHKiXp/lC+zho2 EM6XduBcgoRpMMz+5/Kx0ueiiFlkS9RkZZLA73yuVLL1ztH+XxGCnUCfDSkiBIuV OWODRFwmA9ywNLvA/1kXFbLlrk1+U1W7iLo9C5PE5TKllJpTdIxo7fNK0KN/EWxp 3lMTYub5oxsWB6Ghz0RkIpXhWBHhEXuSBx55XoJ7EG6Lni0Tb5/b0478MW+F6+cq 98BWfuk5VqgmY/nZstPi =lNAb -----END PGP SIGNATURE----- From t.nemo10@kmd.keio.ac.jp Wed Jul 24 00:25:40 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 A607011E80F0 for ; Wed, 24 Jul 2013 00:25:40 -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 XuINEYPJjPeE for ; Wed, 24 Jul 2013 00:25:39 -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 830BB11E80E2 for ; Wed, 24 Jul 2013 00:25:38 -0700 (PDT) Received: from [IPv6:2001:200:167:2ec1:1af:90d7:2b43:d4cb] (unknown [IPv6:2001:200:167:2ec1:1af:90d7:2b43:d4cb]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.kmd.keio.ac.jp (Postfix) with ESMTPSA id C0FAF80604; Wed, 24 Jul 2013 16:25:33 +0900 (JST) Content-Type: multipart/alternative; boundary="Apple-Mail=_7452C59E-3459-4509-82D4-6478271249A0" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Takahiro Nemoto In-Reply-To: <51DDBE01.6090605@stpeter.im> Date: Wed, 24 Jul 2013 16:25:41 +0900 Message-Id: <856CF13A-94B7-4389-9468-8AC7999B9460@kmd.keio.ac.jp> References: <51DDBE01.6090605@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1508) Cc: "precis@ietf.org" Subject: Re: [precis] updated framework I-D 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, 24 Jul 2013 07:25:40 -0000 --Apple-Mail=_7452C59E-3459-4509-82D4-6478271249A0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2013/07/11, at 5:03, Peter Saint-Andre wrote: > I have received no feedback about the (IMHO small) ordering issues I > raised several weeks ago: >=20 > http://www.ietf.org/mail-archive/web/precis/current/msg00456.html >=20 > http://www.ietf.org/mail-archive/web/precis/current/msg00459.html Hi Peter-san, My apologies for late reply. I compared precis derived property values=20= that based on framework-09's ordering, and framework-08's values using = my code.=20 The only difference that I found was the change from 'PVALID' to 'ID_DIS = or FREE_PVAL' in the character's value. The characters by these changes are more rigid for IdentifierClass. I think this new ordering is more preferable. Thanks. Nemo -- Takahiro Nemoto t.nemo10@kmd.keio.ac.jp >=20 > Because the I-D submission deadline is fast approaching, I will soon > submit a revised I-D incorporating my proposed changes (as well as > numerous fixes to the codepoint table). We can discuss these as open > issues at IETF 87 in Berlin. >=20 > Thanks! >=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=_7452C59E-3459-4509-82D4-6478271249A0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii stpeter@stpeter.im> = wrote:

I have received no feedback about the (IMHO small) = ordering issues I
raised several weeks ago:

http://www.ietf.org/mail-archive/web/precis/current/msg00456.html
=
http://www.ietf.org/mail-archive/web/precis/current/msg00459.html
<= /blockquote>
Hi Peter-san,

My apologies for late reply. I = compared precis derived property values 
that based on = framework-09's ordering, and framework-08's values using my = code. 

The only difference that I found = was the change from 'PVALID' to 'ID_DIS or FREE_PVAL' in the = character's value.
The characters by these changes are = more rigid for IdentifierClass.
I think this new = ordering is more = preferable.

Thanks.

Nemo

--
Takahiro Nemoto
<= blockquote type=3D"cite">
Because the I-D submission deadline is fast = approaching, I will soon
submit a revised I-D incorporating my = proposed changes (as well as
numerous fixes to the codepoint table). = We can discuss these as open
issues at IETF 87 in = Berlin.

Thanks!

Peter

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


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

= --Apple-Mail=_7452C59E-3459-4509-82D4-6478271249A0-- From stpeter@stpeter.im Thu Jul 25 06:39:08 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 63E8821F9AA7 for ; Thu, 25 Jul 2013 06:39:08 -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 mHiEKx9TLw1G for ; Thu, 25 Jul 2013 06:39:04 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id EEB1021F9AAE for ; Thu, 25 Jul 2013 06:39:02 -0700 (PDT) Received: from ergon.local (unknown [63.156.62.121]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 0510D414BF; Thu, 25 Jul 2013 07:40:57 -0600 (MDT) Message-ID: <51F12A76.6060409@stpeter.im> Date: Thu, 25 Jul 2013 07:39:02 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Takahiro Nemoto References: <51DDBE01.6090605@stpeter.im> <856CF13A-94B7-4389-9468-8AC7999B9460@kmd.keio.ac.jp> In-Reply-To: <856CF13A-94B7-4389-9468-8AC7999B9460@kmd.keio.ac.jp> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "precis@ietf.org" Subject: Re: [precis] updated framework I-D 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, 25 Jul 2013 13:39:08 -0000 Thanks, Nemo! My Python code still doesn't output the XML format that createtables.rb does, but I will work on that soon (probably after the IETF meeting unless I can find the time this week). BTW, is that XML format documented anywhere? Peter On 7/24/13 1:25 AM, Takahiro Nemoto wrote: > On 2013/07/11, at 5:03, Peter Saint-Andre > wrote: > >> I have received no feedback about the (IMHO small) ordering issues I >> raised several weeks ago: >> >> http://www.ietf.org/mail-archive/web/precis/current/msg00456.html >> >> http://www.ietf.org/mail-archive/web/precis/current/msg00459.html > Hi Peter-san, > > My apologies for late reply. I compared precis derived property values > that based on framework-09's ordering, and framework-08's values using > my code. > > The only difference that I found was the change from 'PVALID' to 'ID_DIS > or FREE_PVAL' in the character's value. > The characters by these changes are more rigid for IdentifierClass. > I think this new ordering is more preferable. > > Thanks. > > Nemo > > -- > Takahiro Nemoto > t.nemo10@kmd.keio.ac.jp >> >> Because the I-D submission deadline is fast approaching, I will soon >> submit a revised I-D incorporating my proposed changes (as well as >> numerous fixes to the codepoint table). We can discuss these as open >> issues at IETF 87 in Berlin. >> >> Thanks! >> >> Peter >> >> -- >> Peter Saint-Andre >> https://stpeter.im/ >> From t.nemo10@kmd.keio.ac.jp Mon Jul 29 01:48: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 7C87F11E80C5 for ; Mon, 29 Jul 2013 01:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] 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 DjKg9svjPnGW for ; Mon, 29 Jul 2013 01:48:14 -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 DCD2211E80A2 for ; Mon, 29 Jul 2013 01:48:00 -0700 (PDT) Received: from dhcp-147e.meeting.ietf.org (dhcp-147e.meeting.ietf.org [130.129.20.126]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.kmd.keio.ac.jp (Postfix) with ESMTPSA id CA1178063B; Mon, 29 Jul 2013 17:47:52 +0900 (JST) Content-Type: multipart/signed; boundary="Apple-Mail=_6F46D468-5080-43E6-B4B2-075CE3809C32"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Takahiro Nemoto In-Reply-To: <51F12A76.6060409@stpeter.im> Date: Mon, 29 Jul 2013 10:47:49 +0200 Message-Id: <26CA3D40-5DF7-4814-87F1-DE9F96F65E97@kmd.keio.ac.jp> References: <51DDBE01.6090605@stpeter.im> <856CF13A-94B7-4389-9468-8AC7999B9460@kmd.keio.ac.jp> <51F12A76.6060409@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1508) Cc: "precis@ietf.org" Subject: Re: [precis] updated framework I-D 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, 29 Jul 2013 08:48:14 -0000 --Apple-Mail=_6F46D468-5080-43E6-B4B2-075CE3809C32 Content-Type: multipart/mixed; boundary="Apple-Mail=_77AEEF8F-5339-4E07-9F84-DB760FC54733" --Apple-Mail=_77AEEF8F-5339-4E07-9F84-DB760FC54733 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=iso-8859-1 Hi, Peter-san All right and sorry for this late reply. I've attached the XML file for Unicode 6.2 to this mail. I kindly ask for your confirmation. Thanks, Nemo On 2013/07/25, at 15:39, Peter Saint-Andre wrote: > Thanks, Nemo! > > My Python code still doesn't output the XML format that createtables.rb > does, but I will work on that soon (probably after the IETF meeting > unless I can find the time this week). > > BTW, is that XML format documented anywhere? > > Peter > > On 7/24/13 1:25 AM, Takahiro Nemoto wrote: >> On 2013/07/11, at 5:03, Peter Saint-Andre > > wrote: >> >>> I have received no feedback about the (IMHO small) ordering issues I >>> raised several weeks ago: >>> >>> http://www.ietf.org/mail-archive/web/precis/current/msg00456.html >>> >>> http://www.ietf.org/mail-archive/web/precis/current/msg00459.html >> Hi Peter-san, >> >> My apologies for late reply. I compared precis derived property values >> that based on framework-09's ordering, and framework-08's values using >> my code. >> >> The only difference that I found was the change from 'PVALID' to 'ID_DIS >> or FREE_PVAL' in the character's value. >> The characters by these changes are more rigid for IdentifierClass. >> I think this new ordering is more preferable. >> >> Thanks. >> >> Nemo >> >> -- >> Takahiro Nemoto >> t.nemo10@kmd.keio.ac.jp >>> >>> Because the I-D submission deadline is fast approaching, I will soon >>> submit a revised I-D incorporating my proposed changes (as well as >>> numerous fixes to the codepoint table). We can discuss these as open >>> issues at IETF 87 in Berlin. >>> >>> Thanks! >>> >>> Peter >>> >>> -- >>> Peter Saint-Andre >>> https://stpeter.im/ >>> --Apple-Mail=_77AEEF8F-5339-4E07-9F84-DB760FC54733 Content-Disposition: attachment; filename=precis-tables.xml Content-Type: application/xml; name="precis-tables.xml" Content-Transfer-Encoding: 7bit PRECIS Parameters 2013-07-28 2013-07-28 IDNA Contextual Rules 2013-07-28 2013-07-28 IETF Review ZERO WIDTH NON-JOINER 200C This may occur in a formally cursive script (such as Arabic) in a context where it breaks a cursive connection as required for orthographic rules, as in the Persian language, for example. It also may occur in Indic scripts in a consonant conjunct context (immediately following a virama), to control required display of such conjuncts. True False; If Canonical_Combining_Class(Before(cp)) .eq. Virama Then True; If RegExpMatch((Joining_Type:{L,D})(Joining_Type:T)*\u200C (Joining_Type:T)*(Joining_Type:{R,D})) Then True; ZERO WIDTH JOINER 200D This may occur in Indic scripts in a consonant conjunct context (immediately following a virama), to control required display of such conjuncts. True False; If Canonical_Combining_Class(Before(cp)) .eq. Virama Then True; MIDDLE DOT 00B7 Between 'l' (U+006C) characters only, used to permit the Catalan character ela geminada to be expressed False False; If Before(cp) .eq. U+006C And After(cp) .eq. U+006C Then True; GREEK LOWER NUMERAL SIGN (KERAIA) 0375 The script of the following character MUST be Greek. False False; If Script(After(cp)) .eq. Greek Then True; HEBREW PUNCTUATION GERESH 05F3 The script of the preceding character MUST be Hebrew. False False; If Script(Before(cp)) .eq. Hebrew Then True; HEBREW PUNCTUATION GERSHAYIM 05F4 The script of the preceding character MUST be Hebrew. False False; If Script(Before(cp)) .eq. Hebrew Then True; KATAKANA MIDDLE DOT 30FB Note that the Script of Katakana Middle Dot is not any of "Hiragana", "Katakana" or "Han". The effect of this rule is to require at least one character in the label to be in one of those scripts. False False; For All Characters: If Script(cp) .in. {Hiragana, Katakana, Han} Then True; End For; ARABIC-INDIC DIGITS 0660-0669 Can not be mixed with Extended Arabic-Indic Digits. False True; For All Characters: If cp .in. 06F0..06F9 Then False; End For; EXTENDED ARABIC-INDIC DIGITS 06F0-06F9 Can not be mixed with Arabic-Indic Digits. False True; For All Characters: If cp .in. 0660..0669 Then False; End For; IDNA Derived Properties Expert Review 0000-001F DISALLOWED NULL..NULL 0020 ID_DIS or FREE_PVAL SPACE 0021-007E PVALID EXCLAMATION MARK..TILDE 007F-009F DISALLOWED NULL..NULL 00A0-00AC ID_DIS or FREE_PVAL NO-BREAK SPACE..NOT SIGN 00AD DISALLOWED SOFT HYPHEN 00AE-00B6 ID_DIS or FREE_PVAL REGISTERED SIGN..PILCROW SIGN 00B7 CONTEXTO MIDDLE DOT 00B8-00BF ID_DIS or FREE_PVAL CEDILLA..INVERTED QUESTION MARK 00C0-00D6 PVALID LATIN CAPITAL LETTER A WITH GRAVE..LATIN CAPITAL LETTER O WITH DIAERESIS 00D7 ID_DIS or FREE_PVAL MULTIPLICATION SIGN 00D8-00F6 PVALID LATIN CAPITAL LETTER O WITH STROKE..LATIN SMALL LETTER O WITH DIAERESIS 00F7 ID_DIS or FREE_PVAL DIVISION SIGN 00F8-0131 PVALID LATIN SMALL LETTER O WITH STROKE..LATIN SMALL LETTER DOTLESS I 0132-0133 ID_DIS or FREE_PVAL LATIN CAPITAL LIGATURE IJ..LATIN SMALL LIGATURE IJ 0134-013E PVALID LATIN CAPITAL LETTER J WITH CIRCUMFLEX..LATIN SMALL LETTER L WITH CARON 013F-0140 ID_DIS or FREE_PVAL LATIN CAPITAL LETTER L WITH MIDDLE DOT..LATIN SMALL LETTER L WITH MIDDLE DOT 0141-0148 PVALID LATIN CAPITAL LETTER L WITH STROKE..LATIN SMALL LETTER N WITH CARON 0149 ID_DIS or FREE_PVAL LATIN SMALL LETTER N PRECEDED BY APOSTROPHE 014A-017E PVALID LATIN CAPITAL LETTER ENG..LATIN SMALL LETTER Z WITH CARON 017F ID_DIS or FREE_PVAL LATIN SMALL LETTER LONG S 0180-01C3 PVALID LATIN SMALL LETTER B WITH STROKE..LATIN LETTER RETROFLEX CLICK 01C4-01CC ID_DIS or FREE_PVAL LATIN CAPITAL LETTER DZ WITH CARON..LATIN SMALL LETTER NJ 01CD-01F0 PVALID LATIN CAPITAL LETTER A WITH CARON..LATIN SMALL LETTER J WITH CARON 01F1-01F3 ID_DIS or FREE_PVAL LATIN CAPITAL LETTER DZ..LATIN SMALL LETTER DZ 01F4-02AF PVALID LATIN CAPITAL LETTER G WITH ACUTE..LATIN SMALL LETTER TURNED H WITH FISHHOOK AND TAIL 02B0-02B8 ID_DIS or FREE_PVAL MODIFIER LETTER SMALL H..MODIFIER LETTER SMALL Y 02B9-02C1 PVALID MODIFIER LETTER PRIME..MODIFIER LETTER REVERSED GLOTTAL STOP 02C2-02C5 ID_DIS or FREE_PVAL MODIFIER LETTER LEFT ARROWHEAD..MODIFIER LETTER DOWN ARROWHEAD 02C6-02D1 PVALID MODIFIER LETTER CIRCUMFLEX ACCENT..MODIFIER LETTER HALF TRIANGULAR COLON 02D2-02EB ID_DIS or FREE_PVAL MODIFIER LETTER CENTRED RIGHT HALF RING..MODIFIER LETTER YANG DEPARTING TONE MARK 02EC PVALID MODIFIER LETTER VOICING 02ED ID_DIS or FREE_PVAL MODIFIER LETTER UNASPIRATED 02EE PVALID MODIFIER LETTER DOUBLE APOSTROPHE 02EF-02FF ID_DIS or FREE_PVAL MODIFIER LETTER LOW DOWN ARROWHEAD..MODIFIER LETTER LOW LEFT ARROW 0300-033F PVALID COMBINING GRAVE ACCENT..COMBINING DOUBLE OVERLINE 0340-0341 ID_DIS or FREE_PVAL COMBINING GRAVE TONE MARK..COMBINING ACUTE TONE MARK 0342 PVALID COMBINING GREEK PERISPOMENI 0343-0344 ID_DIS or FREE_PVAL COMBINING GREEK KORONIS..COMBINING GREEK DIALYTIKA TONOS 0345-034E PVALID COMBINING GREEK YPOGEGRAMMENI..COMBINING UPWARDS ARROW BELOW 034F DISALLOWED COMBINING GRAPHEME JOINER 0350-0373 PVALID COMBINING RIGHT ARROWHEAD ABOVE..GREEK SMALL LETTER ARCHAIC SAMPI 0374 ID_DIS or FREE_PVAL GREEK NUMERAL SIGN 0375 CONTEXTO GREEK LOWER NUMERAL SIGN 0376-0377 PVALID GREEK CAPITAL LETTER PAMPHYLIAN DIGAMMA..GREEK SMALL LETTER PAMPHYLIAN DIGAMMA 0378-0379 UNASSIGNED <RESERVED>..<RESERVED> 037A ID_DIS or FREE_PVAL GREEK YPOGEGRAMMENI 037B-037D PVALID GREEK SMALL REVERSED LUNATE SIGMA SYMBOL..GREEK SMALL REVERSED DOTTED LUNATE SIGMA SYMBOL 037E ID_DIS or FREE_PVAL GREEK QUESTION MARK 037F-0383 UNASSIGNED <RESERVED>..<RESERVED> 0384-0385 ID_DIS or FREE_PVAL GREEK TONOS..GREEK DIALYTIKA TONOS 0386 PVALID GREEK CAPITAL LETTER ALPHA WITH TONOS 0387 ID_DIS or FREE_PVAL GREEK ANO TELEIA 0388-038A PVALID GREEK CAPITAL LETTER EPSILON WITH TONOS..GREEK CAPITAL LETTER IOTA WITH TONOS 038B UNASSIGNED <RESERVED> 038C PVALID GREEK CAPITAL LETTER OMICRON WITH TONOS 038D UNASSIGNED <RESERVED> 038E-03A1 PVALID GREEK CAPITAL LETTER UPSILON WITH TONOS..GREEK CAPITAL LETTER RHO 03A2 UNASSIGNED <RESERVED> 03A3-03CF PVALID GREEK CAPITAL LETTER SIGMA..GREEK CAPITAL KAI SYMBOL 03D0-03D6 ID_DIS or FREE_PVAL GREEK BETA SYMBOL..GREEK PI SYMBOL 03D7-03EF PVALID GREEK KAI SYMBOL..COPTIC SMALL LETTER DEI 03F0-03F2 ID_DIS or FREE_PVAL GREEK KAPPA SYMBOL..GREEK LUNATE SIGMA SYMBOL 03F3 PVALID GREEK LETTER YOT 03F4-03F6 ID_DIS or FREE_PVAL GREEK CAPITAL THETA SYMBOL..GREEK REVERSED LUNATE EPSILON SYMBOL 03F7-03F8 PVALID GREEK CAPITAL LETTER SHO..GREEK SMALL LETTER SHO 03F9 ID_DIS or FREE_PVAL GREEK CAPITAL LUNATE SIGMA SYMBOL 03FA-0481 PVALID GREEK CAPITAL LETTER SAN..CYRILLIC SMALL LETTER KOPPA 0482 ID_DIS or FREE_PVAL CYRILLIC THOUSANDS SIGN 0483-0487 PVALID COMBINING CYRILLIC TITLO..COMBINING CYRILLIC POKRYTIE 0488-0489 ID_DIS or FREE_PVAL COMBINING CYRILLIC HUNDRED THOUSANDS SIGN..COMBINING CYRILLIC MILLIONS SIGN 048A-0527 PVALID CYRILLIC CAPITAL LETTER SHORT I WITH TAIL..CYRILLIC SMALL LETTER SHHA WITH DESCENDER 0528-0530 UNASSIGNED <RESERVED>..<RESERVED> 0531-0556 PVALID ARMENIAN CAPITAL LETTER AYB..ARMENIAN CAPITAL LETTER FEH 0557-0558 UNASSIGNED <RESERVED>..<RESERVED> 0559 PVALID ARMENIAN MODIFIER LETTER LEFT HALF RING 055A-055F ID_DIS or FREE_PVAL ARMENIAN APOSTROPHE..ARMENIAN ABBREVIATION MARK 0560 UNASSIGNED <RESERVED> 0561-0586 PVALID ARMENIAN SMALL LETTER AYB..ARMENIAN SMALL LETTER FEH 0587 ID_DIS or FREE_PVAL ARMENIAN SMALL LIGATURE ECH YIWN 0588 UNASSIGNED <RESERVED> 0589-058A ID_DIS or FREE_PVAL ARMENIAN FULL STOP..ARMENIAN HYPHEN 058B-058E UNASSIGNED <RESERVED>..<RESERVED> 058F ID_DIS or FREE_PVAL ARMENIAN DRAM SIGN 0590 UNASSIGNED <RESERVED> 0591-05BD PVALID HEBREW ACCENT ETNAHTA..HEBREW POINT METEG 05BE ID_DIS or FREE_PVAL HEBREW PUNCTUATION MAQAF 05BF PVALID HEBREW POINT RAFE 05C0 ID_DIS or FREE_PVAL HEBREW PUNCTUATION PASEQ 05C1-05C2 PVALID HEBREW POINT SHIN DOT..HEBREW POINT SIN DOT 05C3 ID_DIS or FREE_PVAL HEBREW PUNCTUATION SOF PASUQ 05C4-05C5 PVALID HEBREW MARK UPPER DOT..HEBREW MARK LOWER DOT 05C6 ID_DIS or FREE_PVAL HEBREW PUNCTUATION NUN HAFUKHA 05C7 PVALID HEBREW POINT QAMATS QATAN 05C8-05CF UNASSIGNED <RESERVED>..<RESERVED> 05D0-05EA PVALID HEBREW LETTER ALEF..HEBREW LETTER TAV 05EB-05EF UNASSIGNED <RESERVED>..<RESERVED> 05F0-05F2 PVALID HEBREW LIGATURE YIDDISH DOUBLE VAV..HEBREW LIGATURE YIDDISH DOUBLE YOD 05F3-05F4 CONTEXTO HEBREW PUNCTUATION GERESH..HEBREW PUNCTUATION GERSHAYIM 05F5-05FF UNASSIGNED <RESERVED>..<RESERVED> 0600-0604 DISALLOWED ARABIC NUMBER SIGN..ARABIC SIGN SAMVAT 0605 UNASSIGNED <RESERVED> 0606-060F ID_DIS or FREE_PVAL ARABIC-INDIC CUBE ROOT..ARABIC SIGN MISRA 0610-061A PVALID ARABIC SIGN SALLALLAHOU ALAYHE WASSALLAM..ARABIC SMALL KASRA 061B ID_DIS or FREE_PVAL ARABIC SEMICOLON 061C-061D UNASSIGNED <RESERVED>..<RESERVED> 061E-061F ID_DIS or FREE_PVAL ARABIC TRIPLE DOT PUNCTUATION MARK..ARABIC QUESTION MARK 0620-063F PVALID ARABIC LETTER KASHMIRI YEH..ARABIC LETTER FARSI YEH WITH THREE DOTS ABOVE 0640 DISALLOWED ARABIC TATWEEL 0641-065F PVALID ARABIC LETTER FEH..ARABIC WAVY HAMZA BELOW 0660-0669 CONTEXTO ARABIC-INDIC DIGIT ZERO..ARABIC-INDIC DIGIT NINE 066A-066D ID_DIS or FREE_PVAL ARABIC PERCENT SIGN..ARABIC FIVE POINTED STAR 066E-0674 PVALID ARABIC LETTER DOTLESS BEH..ARABIC LETTER HIGH HAMZA 0675-0678 ID_DIS or FREE_PVAL ARABIC LETTER HIGH HAMZA ALEF..ARABIC LETTER HIGH HAMZA YEH 0679-06D3 PVALID ARABIC LETTER TTEH..ARABIC LETTER YEH BARREE WITH HAMZA ABOVE 06D4 ID_DIS or FREE_PVAL ARABIC FULL STOP 06D5-06DC PVALID ARABIC LETTER AE..ARABIC SMALL HIGH SEEN 06DD DISALLOWED ARABIC END OF AYAH 06DE ID_DIS or FREE_PVAL ARABIC START OF RUB EL HIZB 06DF-06E8 PVALID ARABIC SMALL HIGH ROUNDED ZERO..ARABIC SMALL HIGH NOON 06E9 ID_DIS or FREE_PVAL ARABIC PLACE OF SAJDAH 06EA-06EF PVALID ARABIC EMPTY CENTRE LOW STOP..ARABIC LETTER REH WITH INVERTED V 06F0-06F9 CONTEXTO EXTENDED ARABIC-INDIC DIGIT ZERO..EXTENDED ARABIC-INDIC DIGIT NINE 06FA-06FF PVALID ARABIC LETTER SHEEN WITH DOT BELOW..ARABIC LETTER HEH WITH INVERTED V 0700-070D ID_DIS or FREE_PVAL SYRIAC END OF PARAGRAPH..SYRIAC HARKLEAN ASTERISCUS 070E UNASSIGNED <RESERVED> 070F DISALLOWED SYRIAC ABBREVIATION MARK 0710-074A PVALID SYRIAC LETTER ALAPH..SYRIAC BARREKH 074B-074C UNASSIGNED <RESERVED>..<RESERVED> 074D-07B1 PVALID SYRIAC LETTER SOGDIAN ZHAIN..THAANA LETTER NAA 07B2-07BF UNASSIGNED <RESERVED>..<RESERVED> 07C0-07F5 PVALID NKO DIGIT ZERO..NKO LOW TONE APOSTROPHE 07F6-07F9 ID_DIS or FREE_PVAL NKO SYMBOL OO DENNEN..NKO EXCLAMATION MARK 07FA DISALLOWED NKO LAJANYALAN 07FB-07FF UNASSIGNED <RESERVED>..<RESERVED> 0800-082D PVALID SAMARITAN LETTER ALAF..SAMARITAN MARK NEQUDAA 082E-082F UNASSIGNED <RESERVED>..<RESERVED> 0830-083E ID_DIS or FREE_PVAL SAMARITAN PUNCTUATION NEQUDAA..SAMARITAN PUNCTUATION ANNAAU 083F UNASSIGNED <RESERVED> 0840-085B PVALID MANDAIC LETTER HALQA..MANDAIC GEMINATION MARK 085C-085D UNASSIGNED <RESERVED>..<RESERVED> 085E ID_DIS or FREE_PVAL MANDAIC PUNCTUATION 085F-089F UNASSIGNED <RESERVED>..<RESERVED> 08A0 PVALID ARABIC LETTER BEH WITH SMALL V BELOW 08A1 UNASSIGNED <RESERVED> 08A2-08AC PVALID ARABIC LETTER JEEM WITH TWO DOTS ABOVE..ARABIC LETTER ROHINGYA YEH 08AD-08E3 UNASSIGNED <RESERVED>..<RESERVED> 08E4-08FE PVALID ARABIC CURLY FATHA..ARABIC DAMMA WITH DOT 08FF UNASSIGNED <RESERVED> 0900-0957 PVALID DEVANAGARI SIGN INVERTED CANDRABINDU..DEVANAGARI VOWEL SIGN UUE 0958-095F ID_DIS or FREE_PVAL DEVANAGARI LETTER QA..DEVANAGARI LETTER YYA 0960-0963 PVALID DEVANAGARI LETTER VOCALIC RR..DEVANAGARI VOWEL SIGN VOCALIC LL 0964-0965 ID_DIS or FREE_PVAL DEVANAGARI DANDA..DEVANAGARI DOUBLE DANDA 0966-096F PVALID DEVANAGARI DIGIT ZERO..DEVANAGARI DIGIT NINE 0970 ID_DIS or FREE_PVAL DEVANAGARI ABBREVIATION SIGN 0971-0977 PVALID DEVANAGARI SIGN HIGH SPACING DOT..DEVANAGARI LETTER UUE 0978 UNASSIGNED <RESERVED> 0979-097F PVALID DEVANAGARI LETTER ZHA..DEVANAGARI LETTER BBA 0980 UNASSIGNED <RESERVED> 0981-0983 PVALID BENGALI SIGN CANDRABINDU..BENGALI SIGN VISARGA 0984 UNASSIGNED <RESERVED> 0985-098C PVALID BENGALI LETTER A..BENGALI LETTER VOCALIC L 098D-098E UNASSIGNED <RESERVED>..<RESERVED> 098F-0990 PVALID BENGALI LETTER E..BENGALI LETTER AI 0991-0992 UNASSIGNED <RESERVED>..<RESERVED> 0993-09A8 PVALID BENGALI LETTER O..BENGALI LETTER NA 09A9 UNASSIGNED <RESERVED> 09AA-09B0 PVALID BENGALI LETTER PA..BENGALI LETTER RA 09B1 UNASSIGNED <RESERVED> 09B2 PVALID BENGALI LETTER LA 09B3-09B5 UNASSIGNED <RESERVED>..<RESERVED> 09B6-09B9 PVALID BENGALI LETTER SHA..BENGALI LETTER HA 09BA-09BB UNASSIGNED <RESERVED>..<RESERVED> 09BC-09C4 PVALID BENGALI SIGN NUKTA..BENGALI VOWEL SIGN VOCALIC RR 09C5-09C6 UNASSIGNED <RESERVED>..<RESERVED> 09C7-09C8 PVALID BENGALI VOWEL SIGN E..BENGALI VOWEL SIGN AI 09C9-09CA UNASSIGNED <RESERVED>..<RESERVED> 09CB-09CE PVALID BENGALI VOWEL SIGN O..BENGALI LETTER KHANDA TA 09CF-09D6 UNASSIGNED <RESERVED>..<RESERVED> 09D7 PVALID BENGALI AU LENGTH MARK 09D8-09DB UNASSIGNED <RESERVED>..<RESERVED> 09DC-09DD ID_DIS or FREE_PVAL BENGALI LETTER RRA..BENGALI LETTER RHA 09DE UNASSIGNED <RESERVED> 09DF ID_DIS or FREE_PVAL BENGALI LETTER YYA 09E0-09E3 PVALID BENGALI LETTER VOCALIC RR..BENGALI VOWEL SIGN VOCALIC LL 09E4-09E5 UNASSIGNED <RESERVED>..<RESERVED> 09E6-09F1 PVALID BENGALI DIGIT ZERO..BENGALI LETTER RA WITH LOWER DIAGONAL 09F2-09FB ID_DIS or FREE_PVAL BENGALI RUPEE MARK..BENGALI GANDA MARK 09FC-0A00 UNASSIGNED <RESERVED>..<RESERVED> 0A01-0A03 PVALID GURMUKHI SIGN ADAK BINDI..GURMUKHI SIGN VISARGA 0A04 UNASSIGNED <RESERVED> 0A05-0A0A PVALID GURMUKHI LETTER A..GURMUKHI LETTER UU 0A0B-0A0E UNASSIGNED <RESERVED>..<RESERVED> 0A0F-0A10 PVALID GURMUKHI LETTER EE..GURMUKHI LETTER AI 0A11-0A12 UNASSIGNED <RESERVED>..<RESERVED> 0A13-0A28 PVALID GURMUKHI LETTER OO..GURMUKHI LETTER NA 0A29 UNASSIGNED <RESERVED> 0A2A-0A30 PVALID GURMUKHI LETTER PA..GURMUKHI LETTER RA 0A31 UNASSIGNED <RESERVED> 0A32 PVALID GURMUKHI LETTER LA 0A33 ID_DIS or FREE_PVAL GURMUKHI LETTER LLA 0A34 UNASSIGNED <RESERVED> 0A35 PVALID GURMUKHI LETTER VA 0A36 ID_DIS or FREE_PVAL GURMUKHI LETTER SHA 0A37 UNASSIGNED <RESERVED> 0A38-0A39 PVALID GURMUKHI LETTER SA..GURMUKHI LETTER HA 0A3A-0A3B UNASSIGNED <RESERVED>..<RESERVED> 0A3C PVALID GURMUKHI SIGN NUKTA 0A3D UNASSIGNED <RESERVED> 0A3E-0A42 PVALID GURMUKHI VOWEL SIGN AA..GURMUKHI VOWEL SIGN UU 0A43-0A46 UNASSIGNED <RESERVED>..<RESERVED> 0A47-0A48 PVALID GURMUKHI VOWEL SIGN EE..GURMUKHI VOWEL SIGN AI 0A49-0A4A UNASSIGNED <RESERVED>..<RESERVED> 0A4B-0A4D PVALID GURMUKHI VOWEL SIGN OO..GURMUKHI SIGN VIRAMA 0A4E-0A50 UNASSIGNED <RESERVED>..<RESERVED> 0A51 PVALID GURMUKHI SIGN UDAAT 0A52-0A58 UNASSIGNED <RESERVED>..<RESERVED> 0A59-0A5B ID_DIS or FREE_PVAL GURMUKHI LETTER KHHA..GURMUKHI LETTER ZA 0A5C PVALID GURMUKHI LETTER RRA 0A5D UNASSIGNED <RESERVED> 0A5E ID_DIS or FREE_PVAL GURMUKHI LETTER FA 0A5F-0A65 UNASSIGNED <RESERVED>..<RESERVED> 0A66-0A75 PVALID GURMUKHI DIGIT ZERO..GURMUKHI SIGN YAKASH 0A76-0A80 UNASSIGNED <RESERVED>..<RESERVED> 0A81-0A83 PVALID GUJARATI SIGN CANDRABINDU..GUJARATI SIGN VISARGA 0A84 UNASSIGNED <RESERVED> 0A85-0A8D PVALID GUJARATI LETTER A..GUJARATI VOWEL CANDRA E 0A8E UNASSIGNED <RESERVED> 0A8F-0A91 PVALID GUJARATI LETTER E..GUJARATI VOWEL CANDRA O 0A92 UNASSIGNED <RESERVED> 0A93-0AA8 PVALID GUJARATI LETTER O..GUJARATI LETTER NA 0AA9 UNASSIGNED <RESERVED> 0AAA-0AB0 PVALID GUJARATI LETTER PA..GUJARATI LETTER RA 0AB1 UNASSIGNED <RESERVED> 0AB2-0AB3 PVALID GUJARATI LETTER LA..GUJARATI LETTER LLA 0AB4 UNASSIGNED <RESERVED> 0AB5-0AB9 PVALID GUJARATI LETTER VA..GUJARATI LETTER HA 0ABA-0ABB UNASSIGNED <RESERVED>..<RESERVED> 0ABC-0AC5 PVALID GUJARATI SIGN NUKTA..GUJARATI VOWEL SIGN CANDRA E 0AC6 UNASSIGNED <RESERVED> 0AC7-0AC9 PVALID GUJARATI VOWEL SIGN E..GUJARATI VOWEL SIGN CANDRA O 0ACA UNASSIGNED <RESERVED> 0ACB-0ACD PVALID GUJARATI VOWEL SIGN O..GUJARATI SIGN VIRAMA 0ACE-0ACF UNASSIGNED <RESERVED>..<RESERVED> 0AD0 PVALID GUJARATI OM 0AD1-0ADF UNASSIGNED <RESERVED>..<RESERVED> 0AE0-0AE3 PVALID GUJARATI LETTER VOCALIC RR..GUJARATI VOWEL SIGN VOCALIC LL 0AE4-0AE5 UNASSIGNED <RESERVED>..<RESERVED> 0AE6-0AEF PVALID GUJARATI DIGIT ZERO..GUJARATI DIGIT NINE 0AF0-0AF1 ID_DIS or FREE_PVAL GUJARATI ABBREVIATION SIGN..GUJARATI RUPEE SIGN 0AF2-0B00 UNASSIGNED <RESERVED>..<RESERVED> 0B01-0B03 PVALID ORIYA SIGN CANDRABINDU..ORIYA SIGN VISARGA 0B04 UNASSIGNED <RESERVED> 0B05-0B0C PVALID ORIYA LETTER A..ORIYA LETTER VOCALIC L 0B0D-0B0E UNASSIGNED <RESERVED>..<RESERVED> 0B0F-0B10 PVALID ORIYA LETTER E..ORIYA LETTER AI 0B11-0B12 UNASSIGNED <RESERVED>..<RESERVED> 0B13-0B28 PVALID ORIYA LETTER O..ORIYA LETTER NA 0B29 UNASSIGNED <RESERVED> 0B2A-0B30 PVALID ORIYA LETTER PA..ORIYA LETTER RA 0B31 UNASSIGNED <RESERVED> 0B32-0B33 PVALID ORIYA LETTER LA..ORIYA LETTER LLA 0B34 UNASSIGNED <RESERVED> 0B35-0B39 PVALID ORIYA LETTER VA..ORIYA LETTER HA 0B3A-0B3B UNASSIGNED <RESERVED>..<RESERVED> 0B3C-0B44 PVALID ORIYA SIGN NUKTA..ORIYA VOWEL SIGN VOCALIC RR 0B45-0B46 UNASSIGNED <RESERVED>..<RESERVED> 0B47-0B48 PVALID ORIYA VOWEL SIGN E..ORIYA VOWEL SIGN AI 0B49-0B4A UNASSIGNED <RESERVED>..<RESERVED> 0B4B-0B4D PVALID ORIYA VOWEL SIGN O..ORIYA SIGN VIRAMA 0B4E-0B55 UNASSIGNED <RESERVED>..<RESERVED> 0B56-0B57 PVALID ORIYA AI LENGTH MARK..ORIYA AU LENGTH MARK 0B58-0B5B UNASSIGNED <RESERVED>..<RESERVED> 0B5C-0B5D ID_DIS or FREE_PVAL ORIYA LETTER RRA..ORIYA LETTER RHA 0B5E UNASSIGNED <RESERVED> 0B5F-0B63 PVALID ORIYA LETTER YYA..ORIYA VOWEL SIGN VOCALIC LL 0B64-0B65 UNASSIGNED <RESERVED>..<RESERVED> 0B66-0B6F PVALID ORIYA DIGIT ZERO..ORIYA DIGIT NINE 0B70 ID_DIS or FREE_PVAL ORIYA ISSHAR 0B71 PVALID ORIYA LETTER WA 0B72-0B77 ID_DIS or FREE_PVAL ORIYA FRACTION ONE QUARTER..ORIYA FRACTION THREE SIXTEENTHS 0B78-0B81 UNASSIGNED <RESERVED>..<RESERVED> 0B82-0B83 PVALID TAMIL SIGN ANUSVARA..TAMIL SIGN VISARGA 0B84 UNASSIGNED <RESERVED> 0B85-0B8A PVALID TAMIL LETTER A..TAMIL LETTER UU 0B8B-0B8D UNASSIGNED <RESERVED>..<RESERVED> 0B8E-0B90 PVALID TAMIL LETTER E..TAMIL LETTER AI 0B91 UNASSIGNED <RESERVED> 0B92-0B95 PVALID TAMIL LETTER O..TAMIL LETTER KA 0B96-0B98 UNASSIGNED <RESERVED>..<RESERVED> 0B99-0B9A PVALID TAMIL LETTER NGA..TAMIL LETTER CA 0B9B UNASSIGNED <RESERVED> 0B9C PVALID TAMIL LETTER JA 0B9D UNASSIGNED <RESERVED> 0B9E-0B9F PVALID TAMIL LETTER NYA..TAMIL LETTER TTA 0BA0-0BA2 UNASSIGNED <RESERVED>..<RESERVED> 0BA3-0BA4 PVALID TAMIL LETTER NNA..TAMIL LETTER TA 0BA5-0BA7 UNASSIGNED <RESERVED>..<RESERVED> 0BA8-0BAA PVALID TAMIL LETTER NA..TAMIL LETTER PA 0BAB-0BAD UNASSIGNED <RESERVED>..<RESERVED> 0BAE-0BB9 PVALID TAMIL LETTER MA..TAMIL LETTER HA 0BBA-0BBD UNASSIGNED <RESERVED>..<RESERVED> 0BBE-0BC2 PVALID TAMIL VOWEL SIGN AA..TAMIL VOWEL SIGN UU 0BC3-0BC5 UNASSIGNED <RESERVED>..<RESERVED> 0BC6-0BC8 PVALID TAMIL VOWEL SIGN E..TAMIL VOWEL SIGN AI 0BC9 UNASSIGNED <RESERVED> 0BCA-0BCD PVALID TAMIL VOWEL SIGN O..TAMIL SIGN VIRAMA 0BCE-0BCF UNASSIGNED <RESERVED>..<RESERVED> 0BD0 PVALID TAMIL OM 0BD1-0BD6 UNASSIGNED <RESERVED>..<RESERVED> 0BD7 PVALID TAMIL AU LENGTH MARK 0BD8-0BE5 UNASSIGNED <RESERVED>..<RESERVED> 0BE6-0BEF PVALID TAMIL DIGIT ZERO..TAMIL DIGIT NINE 0BF0-0BFA ID_DIS or FREE_PVAL TAMIL NUMBER TEN..TAMIL NUMBER SIGN 0BFB-0C00 UNASSIGNED <RESERVED>..<RESERVED> 0C01-0C03 PVALID TELUGU SIGN CANDRABINDU..TELUGU SIGN VISARGA 0C04 UNASSIGNED <RESERVED> 0C05-0C0C PVALID TELUGU LETTER A..TELUGU LETTER VOCALIC L 0C0D UNASSIGNED <RESERVED> 0C0E-0C10 PVALID TELUGU LETTER E..TELUGU LETTER AI 0C11 UNASSIGNED <RESERVED> 0C12-0C28 PVALID TELUGU LETTER O..TELUGU LETTER NA 0C29 UNASSIGNED <RESERVED> 0C2A-0C33 PVALID TELUGU LETTER PA..TELUGU LETTER LLA 0C34 UNASSIGNED <RESERVED> 0C35-0C39 PVALID TELUGU LETTER VA..TELUGU LETTER HA 0C3A-0C3C UNASSIGNED <RESERVED>..<RESERVED> 0C3D-0C44 PVALID TELUGU SIGN AVAGRAHA..TELUGU VOWEL SIGN VOCALIC RR 0C45 UNASSIGNED <RESERVED> 0C46-0C48 PVALID TELUGU VOWEL SIGN E..TELUGU VOWEL SIGN AI 0C49 UNASSIGNED <RESERVED> 0C4A-0C4D PVALID TELUGU VOWEL SIGN O..TELUGU SIGN VIRAMA 0C4E-0C54 UNASSIGNED <RESERVED>..<RESERVED> 0C55-0C56 PVALID TELUGU LENGTH MARK..TELUGU AI LENGTH MARK 0C57 UNASSIGNED <RESERVED> 0C58-0C59 PVALID TELUGU LETTER TSA..TELUGU LETTER DZA 0C5A-0C5F UNASSIGNED <RESERVED>..<RESERVED> 0C60-0C63 PVALID TELUGU LETTER VOCALIC RR..TELUGU VOWEL SIGN VOCALIC LL 0C64-0C65 UNASSIGNED <RESERVED>..<RESERVED> 0C66-0C6F PVALID TELUGU DIGIT ZERO..TELUGU DIGIT NINE 0C70-0C77 UNASSIGNED <RESERVED>..<RESERVED> 0C78-0C7F ID_DIS or FREE_PVAL TELUGU FRACTION DIGIT ZERO FOR ODD POWERS OF FOUR..TELUGU SIGN TUUMU 0C80-0C81 UNASSIGNED <RESERVED>..<RESERVED> 0C82-0C83 PVALID KANNADA SIGN ANUSVARA..KANNADA SIGN VISARGA 0C84 UNASSIGNED <RESERVED> 0C85-0C8C PVALID KANNADA LETTER A..KANNADA LETTER VOCALIC L 0C8D UNASSIGNED <RESERVED> 0C8E-0C90 PVALID KANNADA LETTER E..KANNADA LETTER AI 0C91 UNASSIGNED <RESERVED> 0C92-0CA8 PVALID KANNADA LETTER O..KANNADA LETTER NA 0CA9 UNASSIGNED <RESERVED> 0CAA-0CB3 PVALID KANNADA LETTER PA..KANNADA LETTER LLA 0CB4 UNASSIGNED <RESERVED> 0CB5-0CB9 PVALID KANNADA LETTER VA..KANNADA LETTER HA 0CBA-0CBB UNASSIGNED <RESERVED>..<RESERVED> 0CBC-0CC4 PVALID KANNADA SIGN NUKTA..KANNADA VOWEL SIGN VOCALIC RR 0CC5 UNASSIGNED <RESERVED> 0CC6-0CC8 PVALID KANNADA VOWEL SIGN E..KANNADA VOWEL SIGN AI 0CC9 UNASSIGNED <RESERVED> 0CCA-0CCD PVALID KANNADA VOWEL SIGN O..KANNADA SIGN VIRAMA 0CCE-0CD4 UNASSIGNED <RESERVED>..<RESERVED> 0CD5-0CD6 PVALID KANNADA LENGTH MARK..KANNADA AI LENGTH MARK 0CD7-0CDD UNASSIGNED <RESERVED>..<RESERVED> 0CDE PVALID KANNADA LETTER FA 0CDF UNASSIGNED <RESERVED> 0CE0-0CE3 PVALID KANNADA LETTER VOCALIC RR..KANNADA VOWEL SIGN VOCALIC LL 0CE4-0CE5 UNASSIGNED <RESERVED>..<RESERVED> 0CE6-0CEF PVALID KANNADA DIGIT ZERO..KANNADA DIGIT NINE 0CF0 UNASSIGNED <RESERVED> 0CF1-0CF2 PVALID KANNADA SIGN JIHVAMULIYA..KANNADA SIGN UPADHMANIYA 0CF3-0D01 UNASSIGNED <RESERVED>..<RESERVED> 0D02-0D03 PVALID MALAYALAM SIGN ANUSVARA..MALAYALAM SIGN VISARGA 0D04 UNASSIGNED <RESERVED> 0D05-0D0C PVALID MALAYALAM LETTER A..MALAYALAM LETTER VOCALIC L 0D0D UNASSIGNED <RESERVED> 0D0E-0D10 PVALID MALAYALAM LETTER E..MALAYALAM LETTER AI 0D11 UNASSIGNED <RESERVED> 0D12-0D3A PVALID MALAYALAM LETTER O..MALAYALAM LETTER TTTA 0D3B-0D3C UNASSIGNED <RESERVED>..<RESERVED> 0D3D-0D44 PVALID MALAYALAM SIGN AVAGRAHA..MALAYALAM VOWEL SIGN VOCALIC RR 0D45 UNASSIGNED <RESERVED> 0D46-0D48 PVALID MALAYALAM VOWEL SIGN E..MALAYALAM VOWEL SIGN AI 0D49 UNASSIGNED <RESERVED> 0D4A-0D4E PVALID MALAYALAM VOWEL SIGN O..MALAYALAM LETTER DOT REPH 0D4F-0D56 UNASSIGNED <RESERVED>..<RESERVED> 0D57 PVALID MALAYALAM AU LENGTH MARK 0D58-0D5F UNASSIGNED <RESERVED>..<RESERVED> 0D60-0D63 PVALID MALAYALAM LETTER VOCALIC RR..MALAYALAM VOWEL SIGN VOCALIC LL 0D64-0D65 UNASSIGNED <RESERVED>..<RESERVED> 0D66-0D6F PVALID MALAYALAM DIGIT ZERO..MALAYALAM DIGIT NINE 0D70-0D75 ID_DIS or FREE_PVAL MALAYALAM NUMBER TEN..MALAYALAM FRACTION THREE QUARTERS 0D76-0D78 UNASSIGNED <RESERVED>..<RESERVED> 0D79 ID_DIS or FREE_PVAL MALAYALAM DATE MARK 0D7A-0D7F PVALID MALAYALAM LETTER CHILLU NN..MALAYALAM LETTER CHILLU K 0D80-0D81 UNASSIGNED <RESERVED>..<RESERVED> 0D82-0D83 PVALID SINHALA SIGN ANUSVARAYA..SINHALA SIGN VISARGAYA 0D84 UNASSIGNED <RESERVED> 0D85-0D96 PVALID SINHALA LETTER AYANNA..SINHALA LETTER AUYANNA 0D97-0D99 UNASSIGNED <RESERVED>..<RESERVED> 0D9A-0DB1 PVALID SINHALA LETTER ALPAPRAANA KAYANNA..SINHALA LETTER DANTAJA NAYANNA 0DB2 UNASSIGNED <RESERVED> 0DB3-0DBB PVALID SINHALA LETTER SANYAKA DAYANNA..SINHALA LETTER RAYANNA 0DBC UNASSIGNED <RESERVED> 0DBD PVALID SINHALA LETTER DANTAJA LAYANNA 0DBE-0DBF UNASSIGNED <RESERVED>..<RESERVED> 0DC0-0DC6 PVALID SINHALA LETTER VAYANNA..SINHALA LETTER FAYANNA 0DC7-0DC9 UNASSIGNED <RESERVED>..<RESERVED> 0DCA PVALID SINHALA SIGN AL-LAKUNA 0DCB-0DCE UNASSIGNED <RESERVED>..<RESERVED> 0DCF-0DD4 PVALID SINHALA VOWEL SIGN AELA-PILLA..SINHALA VOWEL SIGN KETTI PAA-PILLA 0DD5 UNASSIGNED <RESERVED> 0DD6 PVALID SINHALA VOWEL SIGN DIGA PAA-PILLA 0DD7 UNASSIGNED <RESERVED> 0DD8-0DDF PVALID SINHALA VOWEL SIGN GAETTA-PILLA..SINHALA VOWEL SIGN GAYANUKITTA 0DE0-0DF1 UNASSIGNED <RESERVED>..<RESERVED> 0DF2-0DF3 PVALID SINHALA VOWEL SIGN DIGA GAETTA-PILLA..SINHALA VOWEL SIGN DIGA GAYANUKITTA 0DF4 ID_DIS or FREE_PVAL SINHALA PUNCTUATION KUNDDALIYA 0DF5-0E00 UNASSIGNED <RESERVED>..<RESERVED> 0E01-0E32 PVALID THAI CHARACTER KO KAI..THAI CHARACTER SARA AA 0E33 ID_DIS or FREE_PVAL THAI CHARACTER SARA AM 0E34-0E3A PVALID THAI CHARACTER SARA I..THAI CHARACTER PHINTHU 0E3B-0E3E UNASSIGNED <RESERVED>..<RESERVED> 0E3F ID_DIS or FREE_PVAL THAI CURRENCY SYMBOL BAHT 0E40-0E4E PVALID THAI CHARACTER SARA E..THAI CHARACTER YAMAKKAN 0E4F ID_DIS or FREE_PVAL THAI CHARACTER FONGMAN 0E50-0E59 PVALID THAI DIGIT ZERO..THAI DIGIT NINE 0E5A-0E5B ID_DIS or FREE_PVAL THAI CHARACTER ANGKHANKHU..THAI CHARACTER KHOMUT 0E5C-0E80 UNASSIGNED <RESERVED>..<RESERVED> 0E81-0E82 PVALID LAO LETTER KO..LAO LETTER KHO SUNG 0E83 UNASSIGNED <RESERVED> 0E84 PVALID LAO LETTER KHO TAM 0E85-0E86 UNASSIGNED <RESERVED>..<RESERVED> 0E87-0E88 PVALID LAO LETTER NGO..LAO LETTER CO 0E89 UNASSIGNED <RESERVED> 0E8A PVALID LAO LETTER SO TAM 0E8B-0E8C UNASSIGNED <RESERVED>..<RESERVED> 0E8D PVALID LAO LETTER NYO 0E8E-0E93 UNASSIGNED <RESERVED>..<RESERVED> 0E94-0E97 PVALID LAO LETTER DO..LAO LETTER THO TAM 0E98 UNASSIGNED <RESERVED> 0E99-0E9F PVALID LAO LETTER NO..LAO LETTER FO SUNG 0EA0 UNASSIGNED <RESERVED> 0EA1-0EA3 PVALID LAO LETTER MO..LAO LETTER LO LING 0EA4 UNASSIGNED <RESERVED> 0EA5 PVALID LAO LETTER LO LOOT 0EA6 UNASSIGNED <RESERVED> 0EA7 PVALID LAO LETTER WO 0EA8-0EA9 UNASSIGNED <RESERVED>..<RESERVED> 0EAA-0EAB PVALID LAO LETTER SO SUNG..LAO LETTER HO SUNG 0EAC UNASSIGNED <RESERVED> 0EAD-0EB2 PVALID LAO LETTER O..LAO VOWEL SIGN AA 0EB3 ID_DIS or FREE_PVAL LAO VOWEL SIGN AM 0EB4-0EB9 PVALID LAO VOWEL SIGN I..LAO VOWEL SIGN UU 0EBA UNASSIGNED <RESERVED> 0EBB-0EBD PVALID LAO VOWEL SIGN MAI KON..LAO SEMIVOWEL SIGN NYO 0EBE-0EBF UNASSIGNED <RESERVED>..<RESERVED> 0EC0-0EC4 PVALID LAO VOWEL SIGN E..LAO VOWEL SIGN AI 0EC5 UNASSIGNED <RESERVED> 0EC6 PVALID LAO KO LA 0EC7 UNASSIGNED <RESERVED> 0EC8-0ECD PVALID LAO TONE MAI EK..LAO NIGGAHITA 0ECE-0ECF UNASSIGNED <RESERVED>..<RESERVED> 0ED0-0ED9 PVALID LAO DIGIT ZERO..LAO DIGIT NINE 0EDA-0EDB UNASSIGNED <RESERVED>..<RESERVED> 0EDC-0EDD ID_DIS or FREE_PVAL LAO HO NO..LAO HO MO 0EDE-0EDF PVALID LAO LETTER KHMU GO..LAO LETTER KHMU NYO 0EE0-0EFF UNASSIGNED <RESERVED>..<RESERVED> 0F00 PVALID TIBETAN SYLLABLE OM 0F01-0F0A ID_DIS or FREE_PVAL TIBETAN MARK GTER YIG MGO TRUNCATED A..TIBETAN MARK BKA- SHOG YIG MGO 0F0B PVALID TIBETAN MARK INTERSYLLABIC TSHEG 0F0C-0F17 ID_DIS or FREE_PVAL TIBETAN MARK DELIMITER TSHEG BSTAR..TIBETAN ASTROLOGICAL SIGN SGRA GCAN -CHAR RTAGS 0F18-0F19 PVALID TIBETAN ASTROLOGICAL SIGN -KHYUD PA..TIBETAN ASTROLOGICAL SIGN SDONG TSHUGS 0F1A-0F1F ID_DIS or FREE_PVAL TIBETAN SIGN RDEL DKAR GCIG..TIBETAN SIGN RDEL DKAR RDEL NAG 0F20-0F29 PVALID TIBETAN DIGIT ZERO..TIBETAN DIGIT NINE 0F2A-0F34 ID_DIS or FREE_PVAL TIBETAN DIGIT HALF ONE..TIBETAN MARK BSDUS RTAGS 0F35 PVALID TIBETAN MARK NGAS BZUNG NYI ZLA 0F36 ID_DIS or FREE_PVAL TIBETAN MARK CARET -DZUD RTAGS BZHI MIG CAN 0F37 PVALID TIBETAN MARK NGAS BZUNG SGOR RTAGS 0F38 ID_DIS or FREE_PVAL TIBETAN MARK CHE MGO 0F39 PVALID TIBETAN MARK TSA -PHRU 0F3A-0F3D ID_DIS or FREE_PVAL TIBETAN MARK GUG RTAGS GYON..TIBETAN MARK ANG KHANG GYAS 0F3E-0F42 PVALID TIBETAN SIGN YAR TSHES..TIBETAN LETTER GA 0F43 ID_DIS or FREE_PVAL TIBETAN LETTER GHA 0F44-0F47 PVALID TIBETAN LETTER NGA..TIBETAN LETTER JA 0F48 UNASSIGNED <RESERVED> 0F49-0F4C PVALID TIBETAN LETTER NYA..TIBETAN LETTER DDA 0F4D ID_DIS or FREE_PVAL TIBETAN LETTER DDHA 0F4E-0F51 PVALID TIBETAN LETTER NNA..TIBETAN LETTER DA 0F52 ID_DIS or FREE_PVAL TIBETAN LETTER DHA 0F53-0F56 PVALID TIBETAN LETTER NA..TIBETAN LETTER BA 0F57 ID_DIS or FREE_PVAL TIBETAN LETTER BHA 0F58-0F5B PVALID TIBETAN LETTER MA..TIBETAN LETTER DZA 0F5C ID_DIS or FREE_PVAL TIBETAN LETTER DZHA 0F5D-0F68 PVALID TIBETAN LETTER WA..TIBETAN LETTER A 0F69 ID_DIS or FREE_PVAL TIBETAN LETTER KSSA 0F6A-0F6C PVALID TIBETAN LETTER FIXED-FORM RA..TIBETAN LETTER RRA 0F6D-0F70 UNASSIGNED <RESERVED>..<RESERVED> 0F71-0F72 PVALID TIBETAN VOWEL SIGN AA..TIBETAN VOWEL SIGN I 0F73 ID_DIS or FREE_PVAL TIBETAN VOWEL SIGN II 0F74 PVALID TIBETAN VOWEL SIGN U 0F75-0F79 ID_DIS or FREE_PVAL TIBETAN VOWEL SIGN UU..TIBETAN VOWEL SIGN VOCALIC LL 0F7A-0F80 PVALID TIBETAN VOWEL SIGN E..TIBETAN VOWEL SIGN REVERSED I 0F81 ID_DIS or FREE_PVAL TIBETAN VOWEL SIGN REVERSED II 0F82-0F84 PVALID TIBETAN SIGN NYI ZLA NAA DA..TIBETAN MARK HALANTA 0F85 ID_DIS or FREE_PVAL TIBETAN MARK PALUTA 0F86-0F92 PVALID TIBETAN SIGN LCI RTAGS..TIBETAN SUBJOINED LETTER GA 0F93 ID_DIS or FREE_PVAL TIBETAN SUBJOINED LETTER GHA 0F94-0F97 PVALID TIBETAN SUBJOINED LETTER NGA..TIBETAN SUBJOINED LETTER JA 0F98 UNASSIGNED <RESERVED> 0F99-0F9C PVALID TIBETAN SUBJOINED LETTER NYA..TIBETAN SUBJOINED LETTER DDA 0F9D ID_DIS or FREE_PVAL TIBETAN SUBJOINED LETTER DDHA 0F9E-0FA1 PVALID TIBETAN SUBJOINED LETTER NNA..TIBETAN SUBJOINED LETTER DA 0FA2 ID_DIS or FREE_PVAL TIBETAN SUBJOINED LETTER DHA 0FA3-0FA6 PVALID TIBETAN SUBJOINED LETTER NA..TIBETAN SUBJOINED LETTER BA 0FA7 ID_DIS or FREE_PVAL TIBETAN SUBJOINED LETTER BHA 0FA8-0FAB PVALID TIBETAN SUBJOINED LETTER MA..TIBETAN SUBJOINED LETTER DZA 0FAC ID_DIS or FREE_PVAL TIBETAN SUBJOINED LETTER DZHA 0FAD-0FB8 PVALID TIBETAN SUBJOINED LETTER WA..TIBETAN SUBJOINED LETTER A 0FB9 ID_DIS or FREE_PVAL TIBETAN SUBJOINED LETTER KSSA 0FBA-0FBC PVALID TIBETAN SUBJOINED LETTER FIXED-FORM WA..TIBETAN SUBJOINED LETTER FIXED-FORM RA 0FBD UNASSIGNED <RESERVED> 0FBE-0FC5 ID_DIS or FREE_PVAL TIBETAN KU RU KHA..TIBETAN SYMBOL RDO RJE 0FC6 PVALID TIBETAN SYMBOL PADMA GDAN 0FC7-0FCC ID_DIS or FREE_PVAL TIBETAN SYMBOL RDO RJE RGYA GRAM..TIBETAN SYMBOL NOR BU BZHI -KHYIL 0FCD UNASSIGNED <RESERVED> 0FCE-0FDA ID_DIS or FREE_PVAL TIBETAN SIGN RDEL NAG RDEL DKAR..TIBETAN MARK TRAILING MCHAN RTAGS 0FDB-0FFF UNASSIGNED <RESERVED>..<RESERVED> 1000-1049 PVALID MYANMAR LETTER KA..MYANMAR DIGIT NINE 104A-104F ID_DIS or FREE_PVAL MYANMAR SIGN LITTLE SECTION..MYANMAR SYMBOL GENITIVE 1050-109D PVALID MYANMAR LETTER SHA..MYANMAR VOWEL SIGN AITON AI 109E-109F ID_DIS or FREE_PVAL MYANMAR SYMBOL SHAN ONE..MYANMAR SYMBOL SHAN EXCLAMATION 10A0-10C5 PVALID GEORGIAN CAPITAL LETTER AN..GEORGIAN CAPITAL LETTER HOE 10C6 UNASSIGNED <RESERVED> 10C7 PVALID GEORGIAN CAPITAL LETTER YN 10C8-10CC UNASSIGNED <RESERVED>..<RESERVED> 10CD PVALID GEORGIAN CAPITAL LETTER AEN 10CE-10CF UNASSIGNED <RESERVED>..<RESERVED> 10D0-10FA PVALID GEORGIAN LETTER AN..GEORGIAN LETTER AIN 10FB-10FC ID_DIS or FREE_PVAL GEORGIAN PARAGRAPH SEPARATOR..MODIFIER LETTER GEORGIAN NAR 10FD-10FF PVALID GEORGIAN LETTER AEN..GEORGIAN LETTER LABIAL SIGN 1100-11FF DISALLOWED HANGUL CHOSEONG KIYEOK..HANGUL JONGSEONG SSANGNIEUN 1200-1248 PVALID ETHIOPIC SYLLABLE HA..ETHIOPIC SYLLABLE QWA 1249 UNASSIGNED <RESERVED> 124A-124D PVALID ETHIOPIC SYLLABLE QWI..ETHIOPIC SYLLABLE QWE 124E-124F UNASSIGNED <RESERVED>..<RESERVED> 1250-1256 PVALID ETHIOPIC SYLLABLE QHA..ETHIOPIC SYLLABLE QHO 1257 UNASSIGNED <RESERVED> 1258 PVALID ETHIOPIC SYLLABLE QHWA 1259 UNASSIGNED <RESERVED> 125A-125D PVALID ETHIOPIC SYLLABLE QHWI..ETHIOPIC SYLLABLE QHWE 125E-125F UNASSIGNED <RESERVED>..<RESERVED> 1260-1288 PVALID ETHIOPIC SYLLABLE BA..ETHIOPIC SYLLABLE XWA 1289 UNASSIGNED <RESERVED> 128A-128D PVALID ETHIOPIC SYLLABLE XWI..ETHIOPIC SYLLABLE XWE 128E-128F UNASSIGNED <RESERVED>..<RESERVED> 1290-12B0 PVALID ETHIOPIC SYLLABLE NA..ETHIOPIC SYLLABLE KWA 12B1 UNASSIGNED <RESERVED> 12B2-12B5 PVALID ETHIOPIC SYLLABLE KWI..ETHIOPIC SYLLABLE KWE 12B6-12B7 UNASSIGNED <RESERVED>..<RESERVED> 12B8-12BE PVALID ETHIOPIC SYLLABLE KXA..ETHIOPIC SYLLABLE KXO 12BF UNASSIGNED <RESERVED> 12C0 PVALID ETHIOPIC SYLLABLE KXWA 12C1 UNASSIGNED <RESERVED> 12C2-12C5 PVALID ETHIOPIC SYLLABLE KXWI..ETHIOPIC SYLLABLE KXWE 12C6-12C7 UNASSIGNED <RESERVED>..<RESERVED> 12C8-12D6 PVALID ETHIOPIC SYLLABLE WA..ETHIOPIC SYLLABLE PHARYNGEAL O 12D7 UNASSIGNED <RESERVED> 12D8-1310 PVALID ETHIOPIC SYLLABLE ZA..ETHIOPIC SYLLABLE GWA 1311 UNASSIGNED <RESERVED> 1312-1315 PVALID ETHIOPIC SYLLABLE GWI..ETHIOPIC SYLLABLE GWE 1316-1317 UNASSIGNED <RESERVED>..<RESERVED> 1318-135A PVALID ETHIOPIC SYLLABLE GGA..ETHIOPIC SYLLABLE FYA 135B-135C UNASSIGNED <RESERVED>..<RESERVED> 135D-135F PVALID ETHIOPIC COMBINING GEMINATION AND VOWEL LENGTH MARK..ETHIOPIC COMBINING GEMINATION MARK 1360-137C ID_DIS or FREE_PVAL ETHIOPIC SECTION MARK..ETHIOPIC NUMBER TEN THOUSAND 137D-137F UNASSIGNED <RESERVED>..<RESERVED> 1380-138F PVALID ETHIOPIC SYLLABLE SEBATBEIT MWA..ETHIOPIC SYLLABLE PWE 1390-1399 ID_DIS or FREE_PVAL ETHIOPIC TONAL MARK YIZET..ETHIOPIC TONAL MARK KURT 139A-139F UNASSIGNED <RESERVED>..<RESERVED> 13A0-13F4 PVALID CHEROKEE LETTER A..CHEROKEE LETTER YV 13F5-13FF UNASSIGNED <RESERVED>..<RESERVED> 1400 ID_DIS or FREE_PVAL CANADIAN SYLLABICS HYPHEN 1401-166C PVALID CANADIAN SYLLABICS E..CANADIAN SYLLABICS CARRIER TTSA 166D-166E ID_DIS or FREE_PVAL CANADIAN SYLLABICS CHI SIGN..CANADIAN SYLLABICS FULL STOP 166F-167F PVALID CANADIAN SYLLABICS QAI..CANADIAN SYLLABICS BLACKFOOT W 1680 ID_DIS or FREE_PVAL OGHAM SPACE MARK 1681-169A PVALID OGHAM LETTER BEITH..OGHAM LETTER PEITH 169B-169C ID_DIS or FREE_PVAL OGHAM FEATHER MARK..OGHAM REVERSED FEATHER MARK 169D-169F UNASSIGNED <RESERVED>..<RESERVED> 16A0-16EA PVALID RUNIC LETTER FEHU FEOH FE F..RUNIC LETTER X 16EB-16F0 ID_DIS or FREE_PVAL RUNIC SINGLE PUNCTUATION..RUNIC BELGTHOR SYMBOL 16F1-16FF UNASSIGNED <RESERVED>..<RESERVED> 1700-170C PVALID TAGALOG LETTER A..TAGALOG LETTER YA 170D UNASSIGNED <RESERVED> 170E-1714 PVALID TAGALOG LETTER LA..TAGALOG SIGN VIRAMA 1715-171F UNASSIGNED <RESERVED>..<RESERVED> 1720-1734 PVALID HANUNOO LETTER A..HANUNOO SIGN PAMUDPOD 1735-1736 ID_DIS or FREE_PVAL PHILIPPINE SINGLE PUNCTUATION..PHILIPPINE DOUBLE PUNCTUATION 1737-173F UNASSIGNED <RESERVED>..<RESERVED> 1740-1753 PVALID BUHID LETTER A..BUHID VOWEL SIGN U 1754-175F UNASSIGNED <RESERVED>..<RESERVED> 1760-176C PVALID TAGBANWA LETTER A..TAGBANWA LETTER YA 176D UNASSIGNED <RESERVED> 176E-1770 PVALID TAGBANWA LETTER LA..TAGBANWA LETTER SA 1771 UNASSIGNED <RESERVED> 1772-1773 PVALID TAGBANWA VOWEL SIGN I..TAGBANWA VOWEL SIGN U 1774-177F UNASSIGNED <RESERVED>..<RESERVED> 1780-17B3 PVALID KHMER LETTER KA..KHMER INDEPENDENT VOWEL QAU 17B4-17B5 DISALLOWED KHMER VOWEL INHERENT AQ..KHMER VOWEL INHERENT AA 17B6-17D3 PVALID KHMER VOWEL SIGN AA..KHMER SIGN BATHAMASAT 17D4-17D6 ID_DIS or FREE_PVAL KHMER SIGN KHAN..KHMER SIGN CAMNUC PII KUUH 17D7 PVALID KHMER SIGN LEK TOO 17D8-17DB ID_DIS or FREE_PVAL KHMER SIGN BEYYAL..KHMER CURRENCY SYMBOL RIEL 17DC-17DD PVALID KHMER SIGN AVAKRAHASANYA..KHMER SIGN ATTHACAN 17DE-17DF UNASSIGNED <RESERVED>..<RESERVED> 17E0-17E9 PVALID KHMER DIGIT ZERO..KHMER DIGIT NINE 17EA-17EF UNASSIGNED <RESERVED>..<RESERVED> 17F0-17F9 ID_DIS or FREE_PVAL KHMER SYMBOL LEK ATTAK SON..KHMER SYMBOL LEK ATTAK PRAM-BUON 17FA-17FF UNASSIGNED <RESERVED>..<RESERVED> 1800-180A ID_DIS or FREE_PVAL MONGOLIAN BIRGA..MONGOLIAN NIRUGU 180B-180D DISALLOWED MONGOLIAN FREE VARIATION SELECTOR ONE..MONGOLIAN FREE VARIATION SELECTOR THREE 180E ID_DIS or FREE_PVAL MONGOLIAN VOWEL SEPARATOR 180F UNASSIGNED <RESERVED> 1810-1819 PVALID MONGOLIAN DIGIT ZERO..MONGOLIAN DIGIT NINE 181A-181F UNASSIGNED <RESERVED>..<RESERVED> 1820-1877 PVALID MONGOLIAN LETTER A..MONGOLIAN LETTER MANCHU ZHA 1878-187F UNASSIGNED <RESERVED>..<RESERVED> 1880-18AA PVALID MONGOLIAN LETTER ALI GALI ANUSVARA ONE..MONGOLIAN LETTER MANCHU ALI GALI LHA 18AB-18AF UNASSIGNED <RESERVED>..<RESERVED> 18B0-18F5 PVALID CANADIAN SYLLABICS OY..CANADIAN SYLLABICS CARRIER DENTAL S 18F6-18FF UNASSIGNED <RESERVED>..<RESERVED> 1900-191C PVALID LIMBU VOWEL-CARRIER LETTER..LIMBU LETTER HA 191D-191F UNASSIGNED <RESERVED>..<RESERVED> 1920-192B PVALID LIMBU VOWEL SIGN A..LIMBU SUBJOINED LETTER WA 192C-192F UNASSIGNED <RESERVED>..<RESERVED> 1930-193B PVALID LIMBU SMALL LETTER KA..LIMBU SIGN SA-I 193C-193F UNASSIGNED <RESERVED>..<RESERVED> 1940 ID_DIS or FREE_PVAL LIMBU SIGN LOO 1941-1943 UNASSIGNED <RESERVED>..<RESERVED> 1944-1945 ID_DIS or FREE_PVAL LIMBU EXCLAMATION MARK..LIMBU QUESTION MARK 1946-196D PVALID LIMBU DIGIT ZERO..TAI LE LETTER AI 196E-196F UNASSIGNED <RESERVED>..<RESERVED> 1970-1974 PVALID TAI LE LETTER TONE-2..TAI LE LETTER TONE-6 1975-197F UNASSIGNED <RESERVED>..<RESERVED> 1980-19AB PVALID NEW TAI LUE LETTER HIGH QA..NEW TAI LUE LETTER LOW SUA 19AC-19AF UNASSIGNED <RESERVED>..<RESERVED> 19B0-19C9 PVALID NEW TAI LUE VOWEL SIGN VOWEL SHORTENER..NEW TAI LUE TONE MARK-2 19CA-19CF UNASSIGNED <RESERVED>..<RESERVED> 19D0-19D9 PVALID NEW TAI LUE DIGIT ZERO..NEW TAI LUE DIGIT NINE 19DA ID_DIS or FREE_PVAL NEW TAI LUE THAM DIGIT ONE 19DB-19DD UNASSIGNED <RESERVED>..<RESERVED> 19DE-19FF ID_DIS or FREE_PVAL NEW TAI LUE SIGN LAE..KHMER SYMBOL DAP-PRAM ROC 1A00-1A1B PVALID BUGINESE LETTER KA..BUGINESE VOWEL SIGN AE 1A1C-1A1D UNASSIGNED <RESERVED>..<RESERVED> 1A1E-1A1F ID_DIS or FREE_PVAL BUGINESE PALLAWA..BUGINESE END OF SECTION 1A20-1A5E PVALID TAI THAM LETTER HIGH KA..TAI THAM CONSONANT SIGN SA 1A5F UNASSIGNED <RESERVED> 1A60-1A7C PVALID TAI THAM SIGN SAKOT..TAI THAM SIGN KHUEN-LUE KARAN 1A7D-1A7E UNASSIGNED <RESERVED>..<RESERVED> 1A7F-1A89 PVALID TAI THAM COMBINING CRYPTOGRAMMIC DOT..TAI THAM HORA DIGIT NINE 1A8A-1A8F UNASSIGNED <RESERVED>..<RESERVED> 1A90-1A99 PVALID TAI THAM THAM DIGIT ZERO..TAI THAM THAM DIGIT NINE 1A9A-1A9F UNASSIGNED <RESERVED>..<RESERVED> 1AA0-1AA6 ID_DIS or FREE_PVAL TAI THAM SIGN WIANG..TAI THAM SIGN REVERSED ROTATED RANA 1AA7 PVALID TAI THAM SIGN MAI YAMOK 1AA8-1AAD ID_DIS or FREE_PVAL TAI THAM SIGN KAAN..TAI THAM SIGN CAANG 1AAE-1AFF UNASSIGNED <RESERVED>..<RESERVED> 1B00-1B4B PVALID BALINESE SIGN ULU RICEM..BALINESE LETTER ASYURA SASAK 1B4C-1B4F UNASSIGNED <RESERVED>..<RESERVED> 1B50-1B59 PVALID BALINESE DIGIT ZERO..BALINESE DIGIT NINE 1B5A-1B6A ID_DIS or FREE_PVAL BALINESE PANTI..BALINESE MUSICAL SYMBOL DANG GEDE 1B6B-1B73 PVALID BALINESE MUSICAL SYMBOL COMBINING TEGEH..BALINESE MUSICAL SYMBOL COMBINING GONG 1B74-1B7C ID_DIS or FREE_PVAL BALINESE MUSICAL SYMBOL RIGHT-HAND OPEN DUG..BALINESE MUSICAL SYMBOL LEFT-HAND OPEN PING 1B7D-1B7F UNASSIGNED <RESERVED>..<RESERVED> 1B80-1BF3 PVALID SUNDANESE SIGN PANYECEK..BATAK PANONGONAN 1BF4-1BFB UNASSIGNED <RESERVED>..<RESERVED> 1BFC-1BFF ID_DIS or FREE_PVAL BATAK SYMBOL BINDU NA METEK..BATAK SYMBOL BINDU PANGOLAT 1C00-1C37 PVALID LEPCHA LETTER KA..LEPCHA SIGN NUKTA 1C38-1C3A UNASSIGNED <RESERVED>..<RESERVED> 1C3B-1C3F ID_DIS or FREE_PVAL LEPCHA PUNCTUATION TA-ROL..LEPCHA PUNCTUATION TSHOOK 1C40-1C49 PVALID LEPCHA DIGIT ZERO..LEPCHA DIGIT NINE 1C4A-1C4C UNASSIGNED <RESERVED>..<RESERVED> 1C4D-1C7D PVALID LEPCHA LETTER TTA..OL CHIKI AHAD 1C7E-1C7F ID_DIS or FREE_PVAL OL CHIKI PUNCTUATION MUCAAD..OL CHIKI PUNCTUATION DOUBLE MUCAAD 1C80-1CBF UNASSIGNED <RESERVED>..<RESERVED> 1CC0-1CC7 ID_DIS or FREE_PVAL SUNDANESE PUNCTUATION BINDU SURYA..SUNDANESE PUNCTUATION BINDU BA SATANGA 1CC8-1CCF UNASSIGNED <RESERVED>..<RESERVED> 1CD0-1CD2 PVALID VEDIC TONE KARSHANA..VEDIC TONE PRENKHA 1CD3 ID_DIS or FREE_PVAL VEDIC SIGN NIHSHVASA 1CD4-1CF6 PVALID VEDIC SIGN YAJURVEDIC MIDLINE SVARITA..VEDIC SIGN UPADHMANIYA 1CF7-1CFF UNASSIGNED <RESERVED>..<RESERVED> 1D00-1D2B PVALID LATIN LETTER SMALL CAPITAL A..CYRILLIC LETTER SMALL CAPITAL EL 1D2C-1D2E ID_DIS or FREE_PVAL MODIFIER LETTER CAPITAL A..MODIFIER LETTER CAPITAL B 1D2F PVALID MODIFIER LETTER CAPITAL BARRED B 1D30-1D3A ID_DIS or FREE_PVAL MODIFIER LETTER CAPITAL D..MODIFIER LETTER CAPITAL N 1D3B PVALID MODIFIER LETTER CAPITAL REVERSED N 1D3C-1D4D ID_DIS or FREE_PVAL MODIFIER LETTER CAPITAL O..MODIFIER LETTER SMALL G 1D4E PVALID MODIFIER LETTER SMALL TURNED I 1D4F-1D6A ID_DIS or FREE_PVAL MODIFIER LETTER SMALL K..GREEK SUBSCRIPT SMALL LETTER CHI 1D6B-1D77 PVALID LATIN SMALL LETTER UE..LATIN SMALL LETTER TURNED G 1D78 ID_DIS or FREE_PVAL MODIFIER LETTER CYRILLIC EN 1D79-1D9A PVALID LATIN SMALL LETTER INSULAR G..LATIN SMALL LETTER EZH WITH RETROFLEX HOOK 1D9B-1DBF ID_DIS or FREE_PVAL MODIFIER LETTER SMALL TURNED ALPHA..MODIFIER LETTER SMALL THETA 1DC0-1DE6 PVALID COMBINING DOTTED GRAVE ACCENT..COMBINING LATIN SMALL LETTER Z 1DE7-1DFB UNASSIGNED <RESERVED>..<RESERVED> 1DFC-1E99 PVALID COMBINING DOUBLE INVERTED BREVE BELOW..LATIN SMALL LETTER Y WITH RING ABOVE 1E9A-1E9B ID_DIS or FREE_PVAL LATIN SMALL LETTER A WITH RIGHT HALF RING..LATIN SMALL LETTER LONG S WITH DOT ABOVE 1E9C-1F15 PVALID LATIN SMALL LETTER LONG S WITH DIAGONAL STROKE..GREEK SMALL LETTER EPSILON WITH DASIA AND OXIA 1F16-1F17 UNASSIGNED <RESERVED>..<RESERVED> 1F18-1F1D PVALID GREEK CAPITAL LETTER EPSILON WITH PSILI..GREEK CAPITAL LETTER EPSILON WITH DASIA AND OXIA 1F1E-1F1F UNASSIGNED <RESERVED>..<RESERVED> 1F20-1F45 PVALID GREEK SMALL LETTER ETA WITH PSILI..GREEK SMALL LETTER OMICRON WITH DASIA AND OXIA 1F46-1F47 UNASSIGNED <RESERVED>..<RESERVED> 1F48-1F4D PVALID GREEK CAPITAL LETTER OMICRON WITH PSILI..GREEK CAPITAL LETTER OMICRON WITH DASIA AND OXIA 1F4E-1F4F UNASSIGNED <RESERVED>..<RESERVED> 1F50-1F57 PVALID GREEK SMALL LETTER UPSILON WITH PSILI..GREEK SMALL LETTER UPSILON WITH DASIA AND PERISPOMENI 1F58 UNASSIGNED <RESERVED> 1F59 PVALID GREEK CAPITAL LETTER UPSILON WITH DASIA 1F5A UNASSIGNED <RESERVED> 1F5B PVALID GREEK CAPITAL LETTER UPSILON WITH DASIA AND VARIA 1F5C UNASSIGNED <RESERVED> 1F5D PVALID GREEK CAPITAL LETTER UPSILON WITH DASIA AND OXIA 1F5E UNASSIGNED <RESERVED> 1F5F-1F70 PVALID GREEK CAPITAL LETTER UPSILON WITH DASIA AND PERISPOMENI..GREEK SMALL LETTER ALPHA WITH VARIA 1F71 ID_DIS or FREE_PVAL GREEK SMALL LETTER ALPHA WITH OXIA 1F72 PVALID GREEK SMALL LETTER EPSILON WITH VARIA 1F73 ID_DIS or FREE_PVAL GREEK SMALL LETTER EPSILON WITH OXIA 1F74 PVALID GREEK SMALL LETTER ETA WITH VARIA 1F75 ID_DIS or FREE_PVAL GREEK SMALL LETTER ETA WITH OXIA 1F76 PVALID GREEK SMALL LETTER IOTA WITH VARIA 1F77 ID_DIS or FREE_PVAL GREEK SMALL LETTER IOTA WITH OXIA 1F78 PVALID GREEK SMALL LETTER OMICRON WITH VARIA 1F79 ID_DIS or FREE_PVAL GREEK SMALL LETTER OMICRON WITH OXIA 1F7A PVALID GREEK SMALL LETTER UPSILON WITH VARIA 1F7B ID_DIS or FREE_PVAL GREEK SMALL LETTER UPSILON WITH OXIA 1F7C PVALID GREEK SMALL LETTER OMEGA WITH VARIA 1F7D ID_DIS or FREE_PVAL GREEK SMALL LETTER OMEGA WITH OXIA 1F7E-1F7F UNASSIGNED <RESERVED>..<RESERVED> 1F80-1F87 PVALID GREEK SMALL LETTER ALPHA WITH PSILI AND YPOGEGRAMMENI..GREEK SMALL LETTER ALPHA WITH DASIA AND PERISPOMENI AND YPOGEGRAMMENI 1F88-1F8F ID_DIS or FREE_PVAL GREEK CAPITAL LETTER ALPHA WITH PSILI AND PROSGEGRAMMENI..GREEK CAPITAL LETTER ALPHA WITH DASIA AND PERISPOMENI AND PROSGEGRAMMENI 1F90-1F97 PVALID GREEK SMALL LETTER ETA WITH PSILI AND YPOGEGRAMMENI..GREEK SMALL LETTER ETA WITH DASIA AND PERISPOMENI AND YPOGEGRAMMENI 1F98-1F9F ID_DIS or FREE_PVAL GREEK CAPITAL LETTER ETA WITH PSILI AND PROSGEGRAMMENI..GREEK CAPITAL LETTER ETA WITH DASIA AND PERISPOMENI AND PROSGEGRAMMENI 1FA0-1FA7 PVALID GREEK SMALL LETTER OMEGA WITH PSILI AND YPOGEGRAMMENI..GREEK SMALL LETTER OMEGA WITH DASIA AND PERISPOMENI AND YPOGEGRAMMENI 1FA8-1FAF ID_DIS or FREE_PVAL GREEK CAPITAL LETTER OMEGA WITH PSILI AND PROSGEGRAMMENI..GREEK CAPITAL LETTER OMEGA WITH DASIA AND PERISPOMENI AND PROSGEGRAMMENI 1FB0-1FB4 PVALID GREEK SMALL LETTER ALPHA WITH VRACHY..GREEK SMALL LETTER ALPHA WITH OXIA AND YPOGEGRAMMENI 1FB5 UNASSIGNED <RESERVED> 1FB6-1FBA PVALID GREEK SMALL LETTER ALPHA WITH PERISPOMENI..GREEK CAPITAL LETTER ALPHA WITH VARIA 1FBB-1FC1 ID_DIS or FREE_PVAL GREEK CAPITAL LETTER ALPHA WITH OXIA..GREEK DIALYTIKA AND PERISPOMENI 1FC2-1FC4 PVALID GREEK SMALL LETTER ETA WITH VARIA AND YPOGEGRAMMENI..GREEK SMALL LETTER ETA WITH OXIA AND YPOGEGRAMMENI 1FC5 UNASSIGNED <RESERVED> 1FC6-1FC8 PVALID GREEK SMALL LETTER ETA WITH PERISPOMENI..GREEK CAPITAL LETTER EPSILON WITH VARIA 1FC9 ID_DIS or FREE_PVAL GREEK CAPITAL LETTER EPSILON WITH OXIA 1FCA PVALID GREEK CAPITAL LETTER ETA WITH VARIA 1FCB-1FCF ID_DIS or FREE_PVAL GREEK CAPITAL LETTER ETA WITH OXIA..GREEK PSILI AND PERISPOMENI 1FD0-1FD2 PVALID GREEK SMALL LETTER IOTA WITH VRACHY..GREEK SMALL LETTER IOTA WITH DIALYTIKA AND VARIA 1FD3 ID_DIS or FREE_PVAL GREEK SMALL LETTER IOTA WITH DIALYTIKA AND OXIA 1FD4-1FD5 UNASSIGNED <RESERVED>..<RESERVED> 1FD6-1FDA PVALID GREEK SMALL LETTER IOTA WITH PERISPOMENI..GREEK CAPITAL LETTER IOTA WITH VARIA 1FDB ID_DIS or FREE_PVAL GREEK CAPITAL LETTER IOTA WITH OXIA 1FDC UNASSIGNED <RESERVED> 1FDD-1FDF ID_DIS or FREE_PVAL GREEK DASIA AND VARIA..GREEK DASIA AND PERISPOMENI 1FE0-1FE2 PVALID GREEK SMALL LETTER UPSILON WITH VRACHY..GREEK SMALL LETTER UPSILON WITH DIALYTIKA AND VARIA 1FE3 ID_DIS or FREE_PVAL GREEK SMALL LETTER UPSILON WITH DIALYTIKA AND OXIA 1FE4-1FEA PVALID GREEK SMALL LETTER RHO WITH PSILI..GREEK CAPITAL LETTER UPSILON WITH VARIA 1FEB ID_DIS or FREE_PVAL GREEK CAPITAL LETTER UPSILON WITH OXIA 1FEC PVALID GREEK CAPITAL LETTER RHO WITH DASIA 1FED-1FEF ID_DIS or FREE_PVAL GREEK DIALYTIKA AND VARIA..GREEK VARIA 1FF0-1FF1 UNASSIGNED <RESERVED>..<RESERVED> 1FF2-1FF4 PVALID GREEK SMALL LETTER OMEGA WITH VARIA AND YPOGEGRAMMENI..GREEK SMALL LETTER OMEGA WITH OXIA AND YPOGEGRAMMENI 1FF5 UNASSIGNED <RESERVED> 1FF6-1FF8 PVALID GREEK SMALL LETTER OMEGA WITH PERISPOMENI..GREEK CAPITAL LETTER OMICRON WITH VARIA 1FF9 ID_DIS or FREE_PVAL GREEK CAPITAL LETTER OMICRON WITH OXIA 1FFA PVALID GREEK CAPITAL LETTER OMEGA WITH VARIA 1FFB-1FFE ID_DIS or FREE_PVAL GREEK CAPITAL LETTER OMEGA WITH OXIA..GREEK DASIA 1FFF UNASSIGNED <RESERVED> 2000-200A ID_DIS or FREE_PVAL EN QUAD..HAIR SPACE 200B DISALLOWED ZERO WIDTH SPACE 200C-200D CONTEXTJ ZERO WIDTH NON-JOINER..ZERO WIDTH JOINER 200E-200F DISALLOWED LEFT-TO-RIGHT MARK..RIGHT-TO-LEFT MARK 2010-2027 ID_DIS or FREE_PVAL HYPHEN..HYPHENATION POINT 2028-202E DISALLOWED LINE SEPARATOR..RIGHT-TO-LEFT OVERRIDE 202F-205F ID_DIS or FREE_PVAL NARROW NO-BREAK SPACE..MEDIUM MATHEMATICAL SPACE 2060-2064 DISALLOWED WORD JOINER..INVISIBLE PLUS 2065-2069 UNASSIGNED <RESERVED>..<RESERVED> 206A-206F DISALLOWED INHIBIT SYMMETRIC SWAPPING..NOMINAL DIGIT SHAPES 2070-2071 ID_DIS or FREE_PVAL SUPERSCRIPT ZERO..SUPERSCRIPT LATIN SMALL LETTER I 2072-2073 UNASSIGNED <RESERVED>..<RESERVED> 2074-208E ID_DIS or FREE_PVAL SUPERSCRIPT FOUR..SUBSCRIPT RIGHT PARENTHESIS 208F UNASSIGNED <RESERVED> 2090-209C ID_DIS or FREE_PVAL LATIN SUBSCRIPT SMALL LETTER A..LATIN SUBSCRIPT SMALL LETTER T 209D-209F UNASSIGNED <RESERVED>..<RESERVED> 20A0-20BA ID_DIS or FREE_PVAL EURO-CURRENCY SIGN..TURKISH LIRA SIGN 20BB-20CF UNASSIGNED <RESERVED>..<RESERVED> 20D0-20DC PVALID COMBINING LEFT HARPOON ABOVE..COMBINING FOUR DOTS ABOVE 20DD-20E0 ID_DIS or FREE_PVAL COMBINING ENCLOSING CIRCLE..COMBINING ENCLOSING CIRCLE BACKSLASH 20E1 PVALID COMBINING LEFT RIGHT ARROW ABOVE 20E2-20E4 ID_DIS or FREE_PVAL COMBINING ENCLOSING SCREEN..COMBINING ENCLOSING UPWARD POINTING TRIANGLE 20E5-20F0 PVALID COMBINING REVERSE SOLIDUS OVERLAY..COMBINING ASTERISK ABOVE 20F1-20FF UNASSIGNED <RESERVED>..<RESERVED> 2100-2131 ID_DIS or FREE_PVAL ACCOUNT OF..SCRIPT CAPITAL F 2132 PVALID TURNED CAPITAL F 2133-214D ID_DIS or FREE_PVAL SCRIPT CAPITAL M..AKTIESELSKAB 214E PVALID TURNED SMALL F 214F-2182 ID_DIS or FREE_PVAL SYMBOL FOR SAMARITAN SOURCE..ROMAN NUMERAL TEN THOUSAND 2183-2184 PVALID ROMAN NUMERAL REVERSED ONE HUNDRED..LATIN SMALL LETTER REVERSED C 2185-2189 ID_DIS or FREE_PVAL ROMAN NUMERAL SIX LATE FORM..VULGAR FRACTION ZERO THIRDS 218A-218F UNASSIGNED <RESERVED>..<RESERVED> 2190-23F3 ID_DIS or FREE_PVAL LEFTWARDS ARROW..HOURGLASS WITH FLOWING SAND 23F4-23FF UNASSIGNED <RESERVED>..<RESERVED> 2400-2426 ID_DIS or FREE_PVAL SYMBOL FOR NULL..SYMBOL FOR SUBSTITUTE FORM TWO 2427-243F UNASSIGNED <RESERVED>..<RESERVED> 2440-244A ID_DIS or FREE_PVAL OCR HOOK..OCR DOUBLE BACKSLASH 244B-245F UNASSIGNED <RESERVED>..<RESERVED> 2460-26FF ID_DIS or FREE_PVAL CIRCLED DIGIT ONE..WHITE FLAG WITH HORIZONTAL MIDDLE BLACK STRIPE 2700 UNASSIGNED <RESERVED> 2701-2B4C ID_DIS or FREE_PVAL UPPER BLADE SCISSORS..RIGHTWARDS ARROW ABOVE REVERSE TILDE OPERATOR 2B4D-2B4F UNASSIGNED <RESERVED>..<RESERVED> 2B50-2B59 ID_DIS or FREE_PVAL WHITE MEDIUM STAR..HEAVY CIRCLED SALTIRE 2B5A-2BFF UNASSIGNED <RESERVED>..<RESERVED> 2C00-2C2E PVALID GLAGOLITIC CAPITAL LETTER AZU..GLAGOLITIC CAPITAL LETTER LATINATE MYSLITE 2C2F UNASSIGNED <RESERVED> 2C30-2C5E PVALID GLAGOLITIC SMALL LETTER AZU..GLAGOLITIC SMALL LETTER LATINATE MYSLITE 2C5F UNASSIGNED <RESERVED> 2C60-2C7B PVALID LATIN CAPITAL LETTER L WITH DOUBLE BAR..LATIN LETTER SMALL CAPITAL TURNED E 2C7C-2C7D ID_DIS or FREE_PVAL LATIN SUBSCRIPT SMALL LETTER J..MODIFIER LETTER CAPITAL V 2C7E-2CE4 PVALID LATIN CAPITAL LETTER S WITH SWASH TAIL..COPTIC SYMBOL KAI 2CE5-2CEA ID_DIS or FREE_PVAL COPTIC SYMBOL MI RO..COPTIC SYMBOL SHIMA SIMA 2CEB-2CF3 PVALID COPTIC CAPITAL LETTER CRYPTOGRAMMIC SHEI..COPTIC SMALL LETTER BOHAIRIC KHEI 2CF4-2CF8 UNASSIGNED <RESERVED>..<RESERVED> 2CF9-2CFF ID_DIS or FREE_PVAL COPTIC OLD NUBIAN FULL STOP..COPTIC MORPHOLOGICAL DIVIDER 2D00-2D25 PVALID GEORGIAN SMALL LETTER AN..GEORGIAN SMALL LETTER HOE 2D26 UNASSIGNED <RESERVED> 2D27 PVALID GEORGIAN SMALL LETTER YN 2D28-2D2C UNASSIGNED <RESERVED>..<RESERVED> 2D2D PVALID GEORGIAN SMALL LETTER AEN 2D2E-2D2F UNASSIGNED <RESERVED>..<RESERVED> 2D30-2D67 PVALID TIFINAGH LETTER YA..TIFINAGH LETTER YO 2D68-2D6E UNASSIGNED <RESERVED>..<RESERVED> 2D6F-2D70 ID_DIS or FREE_PVAL TIFINAGH MODIFIER LETTER LABIALIZATION MARK..TIFINAGH SEPARATOR MARK 2D71-2D7E UNASSIGNED <RESERVED>..<RESERVED> 2D7F-2D96 PVALID TIFINAGH CONSONANT JOINER..ETHIOPIC SYLLABLE GGWE 2D97-2D9F UNASSIGNED <RESERVED>..<RESERVED> 2DA0-2DA6 PVALID ETHIOPIC SYLLABLE SSA..ETHIOPIC SYLLABLE SSO 2DA7 UNASSIGNED <RESERVED> 2DA8-2DAE PVALID ETHIOPIC SYLLABLE CCA..ETHIOPIC SYLLABLE CCO 2DAF UNASSIGNED <RESERVED> 2DB0-2DB6 PVALID ETHIOPIC SYLLABLE ZZA..ETHIOPIC SYLLABLE ZZO 2DB7 UNASSIGNED <RESERVED> 2DB8-2DBE PVALID ETHIOPIC SYLLABLE CCHA..ETHIOPIC SYLLABLE CCHO 2DBF UNASSIGNED <RESERVED> 2DC0-2DC6 PVALID ETHIOPIC SYLLABLE QYA..ETHIOPIC SYLLABLE QYO 2DC7 UNASSIGNED <RESERVED> 2DC8-2DCE PVALID ETHIOPIC SYLLABLE KYA..ETHIOPIC SYLLABLE KYO 2DCF UNASSIGNED <RESERVED> 2DD0-2DD6 PVALID ETHIOPIC SYLLABLE XYA..ETHIOPIC SYLLABLE XYO 2DD7 UNASSIGNED <RESERVED> 2DD8-2DDE PVALID ETHIOPIC SYLLABLE GYA..ETHIOPIC SYLLABLE GYO 2DDF UNASSIGNED <RESERVED> 2DE0-2DFF PVALID COMBINING CYRILLIC LETTER BE..COMBINING CYRILLIC LETTER IOTIFIED BIG YUS 2E00-2E2E ID_DIS or FREE_PVAL RIGHT ANGLE SUBSTITUTION MARKER..REVERSED QUESTION MARK 2E2F PVALID VERTICAL TILDE 2E30-2E3B ID_DIS or FREE_PVAL RING POINT..THREE-EM DASH 2E3C-2E7F UNASSIGNED <RESERVED>..<RESERVED> 2E80-2E99 ID_DIS or FREE_PVAL CJK RADICAL REPEAT..CJK RADICAL RAP 2E9A UNASSIGNED <RESERVED> 2E9B-2EF3 ID_DIS or FREE_PVAL CJK RADICAL CHOKE..CJK RADICAL C-SIMPLIFIED TURTLE 2EF4-2EFF UNASSIGNED <RESERVED>..<RESERVED> 2F00-2FD5 ID_DIS or FREE_PVAL KANGXI RADICAL ONE..KANGXI RADICAL FLUTE 2FD6-2FEF UNASSIGNED <RESERVED>..<RESERVED> 2FF0-2FFB ID_DIS or FREE_PVAL IDEOGRAPHIC DESCRIPTION CHARACTER LEFT TO RIGHT..IDEOGRAPHIC DESCRIPTION CHARACTER OVERLAID 2FFC-2FFF UNASSIGNED <RESERVED>..<RESERVED> 3000-3004 ID_DIS or FREE_PVAL IDEOGRAPHIC SPACE..JAPANESE INDUSTRIAL STANDARD SYMBOL 3005-3007 PVALID IDEOGRAPHIC ITERATION MARK..IDEOGRAPHIC NUMBER ZERO 3008-3029 ID_DIS or FREE_PVAL LEFT ANGLE BRACKET..HANGZHOU NUMERAL NINE 302A-302D PVALID IDEOGRAPHIC LEVEL TONE MARK..IDEOGRAPHIC ENTERING TONE MARK 302E-302F DISALLOWED HANGUL SINGLE DOT TONE MARK..HANGUL DOUBLE DOT TONE MARK 3030 ID_DIS or FREE_PVAL WAVY DASH 3031-3035 DISALLOWED VERTICAL KANA REPEAT MARK..VERTICAL KANA REPEAT MARK LOWER HALF 3036-303A ID_DIS or FREE_PVAL CIRCLED POSTAL MARK..HANGZHOU NUMERAL THIRTY 303B DISALLOWED VERTICAL IDEOGRAPHIC ITERATION MARK 303C PVALID MASU MARK 303D-303F ID_DIS or FREE_PVAL PART ALTERNATION MARK..IDEOGRAPHIC HALF FILL SPACE 3040 UNASSIGNED <RESERVED> 3041-3096 PVALID HIRAGANA LETTER SMALL A..HIRAGANA LETTER SMALL KE 3097-3098 UNASSIGNED <RESERVED>..<RESERVED> 3099-309A PVALID COMBINING KATAKANA-HIRAGANA VOICED SOUND MARK..COMBINING KATAKANA-HIRAGANA SEMI-VOICED SOUND MARK 309B-309C ID_DIS or FREE_PVAL KATAKANA-HIRAGANA VOICED SOUND MARK..KATAKANA-HIRAGANA SEMI-VOICED SOUND MARK 309D-309E PVALID HIRAGANA ITERATION MARK..HIRAGANA VOICED ITERATION MARK 309F-30A0 ID_DIS or FREE_PVAL HIRAGANA DIGRAPH YORI..KATAKANA-HIRAGANA DOUBLE HYPHEN 30A1-30FA PVALID KATAKANA LETTER SMALL A..KATAKANA LETTER VO 30FB CONTEXTO KATAKANA MIDDLE DOT 30FC-30FE PVALID KATAKANA-HIRAGANA PROLONGED SOUND MARK..KATAKANA VOICED ITERATION MARK 30FF ID_DIS or FREE_PVAL KATAKANA DIGRAPH KOTO 3100-3104 UNASSIGNED <RESERVED>..<RESERVED> 3105-312D PVALID BOPOMOFO LETTER B..BOPOMOFO LETTER IH 312E-3130 UNASSIGNED <RESERVED>..<RESERVED> 3131-3163 ID_DIS or FREE_PVAL HANGUL LETTER KIYEOK..HANGUL LETTER I 3164 DISALLOWED HANGUL FILLER 3165-318E ID_DIS or FREE_PVAL HANGUL LETTER SSANGNIEUN..HANGUL LETTER ARAEAE 318F UNASSIGNED <RESERVED> 3190-319F ID_DIS or FREE_PVAL IDEOGRAPHIC ANNOTATION LINKING MARK..IDEOGRAPHIC ANNOTATION MAN MARK 31A0-31BA PVALID BOPOMOFO LETTER BU..BOPOMOFO LETTER ZY 31BB-31BF UNASSIGNED <RESERVED>..<RESERVED> 31C0-31E3 ID_DIS or FREE_PVAL CJK STROKE T..CJK STROKE Q 31E4-31EF UNASSIGNED <RESERVED>..<RESERVED> 31F0-31FF PVALID KATAKANA LETTER SMALL KU..KATAKANA LETTER SMALL RO 3200-321E ID_DIS or FREE_PVAL PARENTHESIZED HANGUL KIYEOK..PARENTHESIZED KOREAN CHARACTER O HU 321F UNASSIGNED <RESERVED> 3220-32FE ID_DIS or FREE_PVAL PARENTHESIZED IDEOGRAPH ONE..CIRCLED KATAKANA WO 32FF UNASSIGNED <RESERVED> 3300-33FF ID_DIS or FREE_PVAL SQUARE APAATO..SQUARE GAL 3400-4DB5 PVALID <CJK Ideograph Extension A>..<CJK Ideograph Extension A> 4DB6-4DBF UNASSIGNED <RESERVED>..<RESERVED> 4DC0-4DFF ID_DIS or FREE_PVAL HEXAGRAM FOR THE CREATIVE HEAVEN..HEXAGRAM FOR BEFORE COMPLETION 4E00-9FCC PVALID <CJK Ideograph>..<CJK Ideograph> 9FCD-9FFF UNASSIGNED <RESERVED>..<RESERVED> A000-A48C PVALID YI SYLLABLE IT..YI SYLLABLE YYR A48D-A48F UNASSIGNED <RESERVED>..<RESERVED> A490-A4C6 ID_DIS or FREE_PVAL YI RADICAL QOT..YI RADICAL KE A4C7-A4CF UNASSIGNED <RESERVED>..<RESERVED> A4D0-A4FD PVALID LISU LETTER BA..LISU LETTER TONE MYA JEU A4FE-A4FF ID_DIS or FREE_PVAL LISU PUNCTUATION COMMA..LISU PUNCTUATION FULL STOP A500-A60C PVALID VAI SYLLABLE EE..VAI SYLLABLE LENGTHENER A60D-A60F ID_DIS or FREE_PVAL VAI COMMA..VAI QUESTION MARK A610-A62B PVALID VAI SYLLABLE NDOLE FA..VAI SYLLABLE NDOLE DO A62C-A63F UNASSIGNED <RESERVED>..<RESERVED> A640-A66F PVALID CYRILLIC CAPITAL LETTER ZEMLYA..COMBINING CYRILLIC VZMET A670-A673 ID_DIS or FREE_PVAL COMBINING CYRILLIC TEN MILLIONS SIGN..SLAVONIC ASTERISK A674-A67D PVALID COMBINING CYRILLIC LETTER UKRAINIAN IE..COMBINING CYRILLIC PAYEROK A67E ID_DIS or FREE_PVAL CYRILLIC KAVYKA A67F-A697 PVALID CYRILLIC PAYEROK..CYRILLIC SMALL LETTER SHWE A698-A69E UNASSIGNED <RESERVED>..<RESERVED> A69F-A6E5 PVALID COMBINING CYRILLIC LETTER IOTIFIED E..BAMUM LETTER KI A6E6-A6EF ID_DIS or FREE_PVAL BAMUM LETTER MO..BAMUM LETTER KOGHOM A6F0-A6F1 PVALID BAMUM COMBINING MARK KOQNDON..BAMUM COMBINING MARK TUKWENTIS A6F2-A6F7 ID_DIS or FREE_PVAL BAMUM NJAEMLI..BAMUM QUESTION MARK A6F8-A6FF UNASSIGNED <RESERVED>..<RESERVED> A700-A716 ID_DIS or FREE_PVAL MODIFIER LETTER CHINESE TONE YIN PING..MODIFIER LETTER EXTRA-LOW LEFT-STEM TONE BAR A717-A71F PVALID MODIFIER LETTER DOT VERTICAL BAR..MODIFIER LETTER LOW INVERTED EXCLAMATION MARK A720-A721 ID_DIS or FREE_PVAL MODIFIER LETTER STRESS AND HIGH TONE..MODIFIER LETTER STRESS AND LOW TONE A722-A76F PVALID LATIN CAPITAL LETTER EGYPTOLOGICAL ALEF..LATIN SMALL LETTER CON A770 ID_DIS or FREE_PVAL MODIFIER LETTER US A771-A788 PVALID LATIN SMALL LETTER DUM..MODIFIER LETTER LOW CIRCUMFLEX ACCENT A789-A78A ID_DIS or FREE_PVAL MODIFIER LETTER COLON..MODIFIER LETTER SHORT EQUALS SIGN A78B-A78E PVALID LATIN CAPITAL LETTER SALTILLO..LATIN SMALL LETTER L WITH RETROFLEX HOOK AND BELT A78F UNASSIGNED <RESERVED> A790-A793 PVALID LATIN CAPITAL LETTER N WITH DESCENDER..LATIN SMALL LETTER C WITH BAR A794-A79F UNASSIGNED <RESERVED>..<RESERVED> A7A0-A7AA PVALID LATIN CAPITAL LETTER G WITH OBLIQUE STROKE..LATIN CAPITAL LETTER H WITH HOOK A7AB-A7F7 UNASSIGNED <RESERVED>..<RESERVED> A7F8-A7F9 ID_DIS or FREE_PVAL MODIFIER LETTER CAPITAL H WITH STROKE..MODIFIER LETTER SMALL LIGATURE OE A7FA-A827 PVALID LATIN LETTER SMALL CAPITAL TURNED M..SYLOTI NAGRI VOWEL SIGN OO A828-A82B ID_DIS or FREE_PVAL SYLOTI NAGRI POETRY MARK-1..SYLOTI NAGRI POETRY MARK-4 A82C-A82F UNASSIGNED <RESERVED>..<RESERVED> A830-A839 ID_DIS or FREE_PVAL NORTH INDIC FRACTION ONE QUARTER..NORTH INDIC QUANTITY MARK A83A-A83F UNASSIGNED <RESERVED>..<RESERVED> A840-A873 PVALID PHAGS-PA LETTER KA..PHAGS-PA LETTER CANDRABINDU A874-A877 ID_DIS or FREE_PVAL PHAGS-PA SINGLE HEAD MARK..PHAGS-PA MARK DOUBLE SHAD A878-A87F UNASSIGNED <RESERVED>..<RESERVED> A880-A8C4 PVALID SAURASHTRA SIGN ANUSVARA..SAURASHTRA SIGN VIRAMA A8C5-A8CD UNASSIGNED <RESERVED>..<RESERVED> A8CE-A8CF ID_DIS or FREE_PVAL SAURASHTRA DANDA..SAURASHTRA DOUBLE DANDA A8D0-A8D9 PVALID SAURASHTRA DIGIT ZERO..SAURASHTRA DIGIT NINE A8DA-A8DF UNASSIGNED <RESERVED>..<RESERVED> A8E0-A8F7 PVALID COMBINING DEVANAGARI DIGIT ZERO..DEVANAGARI SIGN CANDRABINDU AVAGRAHA A8F8-A8FA ID_DIS or FREE_PVAL DEVANAGARI SIGN PUSHPIKA..DEVANAGARI CARET A8FB PVALID DEVANAGARI HEADSTROKE A8FC-A8FF UNASSIGNED <RESERVED>..<RESERVED> A900-A92D PVALID KAYAH LI DIGIT ZERO..KAYAH LI TONE CALYA PLOPHU A92E-A92F ID_DIS or FREE_PVAL KAYAH LI SIGN CWI..KAYAH LI SIGN SHYA A930-A953 PVALID REJANG LETTER KA..REJANG VIRAMA A954-A95E UNASSIGNED <RESERVED>..<RESERVED> A95F ID_DIS or FREE_PVAL REJANG SECTION MARK A960-A97C DISALLOWED HANGUL CHOSEONG TIKEUT-MIEUM..HANGUL CHOSEONG SSANGYEORINHIEUH A97D-A97F UNASSIGNED <RESERVED>..<RESERVED> A980-A9C0 PVALID JAVANESE SIGN PANYANGGA..JAVANESE PANGKON A9C1-A9CD ID_DIS or FREE_PVAL JAVANESE LEFT RERENGGAN..JAVANESE TURNED PADA PISELEH A9CE UNASSIGNED <RESERVED> A9CF-A9D9 PVALID JAVANESE PANGRANGKEP..JAVANESE DIGIT NINE A9DA-A9DD UNASSIGNED <RESERVED>..<RESERVED> A9DE-A9DF ID_DIS or FREE_PVAL JAVANESE PADA TIRTA TUMETES..JAVANESE PADA ISEN-ISEN A9E0-A9FF UNASSIGNED <RESERVED>..<RESERVED> AA00-AA36 PVALID CHAM LETTER A..CHAM CONSONANT SIGN WA AA37-AA3F UNASSIGNED <RESERVED>..<RESERVED> AA40-AA4D PVALID CHAM LETTER FINAL K..CHAM CONSONANT SIGN FINAL H AA4E-AA4F UNASSIGNED <RESERVED>..<RESERVED> AA50-AA59 PVALID CHAM DIGIT ZERO..CHAM DIGIT NINE AA5A-AA5B UNASSIGNED <RESERVED>..<RESERVED> AA5C-AA5F ID_DIS or FREE_PVAL CHAM PUNCTUATION SPIRAL..CHAM PUNCTUATION TRIPLE DANDA AA60-AA76 PVALID MYANMAR LETTER KHAMTI GA..MYANMAR LOGOGRAM KHAMTI HM AA77-AA79 ID_DIS or FREE_PVAL MYANMAR SYMBOL AITON EXCLAMATION..MYANMAR SYMBOL AITON TWO AA7A-AA7B PVALID MYANMAR LETTER AITON RA..MYANMAR SIGN PAO KAREN TONE AA7C-AA7F UNASSIGNED <RESERVED>..<RESERVED> AA80-AAC2 PVALID TAI VIET LETTER LOW KO..TAI VIET TONE MAI SONG AAC3-AADA UNASSIGNED <RESERVED>..<RESERVED> AADB-AADD PVALID TAI VIET SYMBOL KON..TAI VIET SYMBOL SAM AADE-AADF ID_DIS or FREE_PVAL TAI VIET SYMBOL HO HOI..TAI VIET SYMBOL KOI KOI AAE0-AAEF PVALID MEETEI MAYEK LETTER E..MEETEI MAYEK VOWEL SIGN AAU AAF0-AAF1 ID_DIS or FREE_PVAL MEETEI MAYEK CHEIKHAN..MEETEI MAYEK AHANG KHUDAM AAF2-AAF6 PVALID MEETEI MAYEK ANJI..MEETEI MAYEK VIRAMA AAF7-AB00 UNASSIGNED <RESERVED>..<RESERVED> AB01-AB06 PVALID ETHIOPIC SYLLABLE TTHU..ETHIOPIC SYLLABLE TTHO AB07-AB08 UNASSIGNED <RESERVED>..<RESERVED> AB09-AB0E PVALID ETHIOPIC SYLLABLE DDHU..ETHIOPIC SYLLABLE DDHO AB0F-AB10 UNASSIGNED <RESERVED>..<RESERVED> AB11-AB16 PVALID ETHIOPIC SYLLABLE DZU..ETHIOPIC SYLLABLE DZO AB17-AB1F UNASSIGNED <RESERVED>..<RESERVED> AB20-AB26 PVALID ETHIOPIC SYLLABLE CCHHA..ETHIOPIC SYLLABLE CCHHO AB27 UNASSIGNED <RESERVED> AB28-AB2E PVALID ETHIOPIC SYLLABLE BBA..ETHIOPIC SYLLABLE BBO AB2F-ABBF UNASSIGNED <RESERVED>..<RESERVED> ABC0-ABEA PVALID MEETEI MAYEK LETTER KOK..MEETEI MAYEK VOWEL SIGN NUNG ABEB ID_DIS or FREE_PVAL MEETEI MAYEK CHEIKHEI ABEC-ABED PVALID MEETEI MAYEK LUM IYEK..MEETEI MAYEK APUN IYEK ABEE-ABEF UNASSIGNED <RESERVED>..<RESERVED> ABF0-ABF9 PVALID MEETEI MAYEK DIGIT ZERO..MEETEI MAYEK DIGIT NINE ABFA-ABFF UNASSIGNED <RESERVED>..<RESERVED> AC00-D7A3 PVALID <Hangul Syllable>..<Hangul Syllable> D7A4-D7AF UNASSIGNED <RESERVED>..<RESERVED> D7B0-D7C6 DISALLOWED HANGUL JUNGSEONG O-YEO..HANGUL JUNGSEONG ARAEA-E D7C7-D7CA UNASSIGNED <RESERVED>..<RESERVED> D7CB-D7FB DISALLOWED HANGUL JONGSEONG NIEUN-RIEUL..HANGUL JONGSEONG PHIEUPH-THIEUTH D7FC-D7FF UNASSIGNED <RESERVED>..<RESERVED> D800-F8FF DISALLOWED <Non Private Use High Surrogate>..<Private Use> F900-FA0D ID_DIS or FREE_PVAL CJK COMPATIBILITY IDEOGRAPH-F900..CJK COMPATIBILITY IDEOGRAPH-FA0D FA0E-FA0F PVALID CJK COMPATIBILITY IDEOGRAPH-FA0E..CJK COMPATIBILITY IDEOGRAPH-FA0F FA10 ID_DIS or FREE_PVAL CJK COMPATIBILITY IDEOGRAPH-FA10 FA11 PVALID CJK COMPATIBILITY IDEOGRAPH-FA11 FA12 ID_DIS or FREE_PVAL CJK COMPATIBILITY IDEOGRAPH-FA12 FA13-FA14 PVALID CJK COMPATIBILITY IDEOGRAPH-FA13..CJK COMPATIBILITY IDEOGRAPH-FA14 FA15-FA1E ID_DIS or FREE_PVAL CJK COMPATIBILITY IDEOGRAPH-FA15..CJK COMPATIBILITY IDEOGRAPH-FA1E FA1F PVALID CJK COMPATIBILITY IDEOGRAPH-FA1F FA20 ID_DIS or FREE_PVAL CJK COMPATIBILITY IDEOGRAPH-FA20 FA21 PVALID CJK COMPATIBILITY IDEOGRAPH-FA21 FA22 ID_DIS or FREE_PVAL CJK COMPATIBILITY IDEOGRAPH-FA22 FA23-FA24 PVALID CJK COMPATIBILITY IDEOGRAPH-FA23..CJK COMPATIBILITY IDEOGRAPH-FA24 FA25-FA26 ID_DIS or FREE_PVAL CJK COMPATIBILITY IDEOGRAPH-FA25..CJK COMPATIBILITY IDEOGRAPH-FA26 FA27-FA29 PVALID CJK COMPATIBILITY IDEOGRAPH-FA27..CJK COMPATIBILITY IDEOGRAPH-FA29 FA2A-FA6D ID_DIS or FREE_PVAL CJK COMPATIBILITY IDEOGRAPH-FA2A..CJK COMPATIBILITY IDEOGRAPH-FA6D FA6E-FA6F UNASSIGNED <RESERVED>..<RESERVED> FA70-FAD9 ID_DIS or FREE_PVAL CJK COMPATIBILITY IDEOGRAPH-FA70..CJK COMPATIBILITY IDEOGRAPH-FAD9 FADA-FAFF UNASSIGNED <RESERVED>..<RESERVED> FB00-FB06 ID_DIS or FREE_PVAL LATIN SMALL LIGATURE FF..LATIN SMALL LIGATURE ST FB07-FB12 UNASSIGNED <RESERVED>..<RESERVED> FB13-FB17 ID_DIS or FREE_PVAL ARMENIAN SMALL LIGATURE MEN NOW..ARMENIAN SMALL LIGATURE MEN XEH FB18-FB1C UNASSIGNED <RESERVED>..<RESERVED> FB1D ID_DIS or FREE_PVAL HEBREW LETTER YOD WITH HIRIQ FB1E PVALID HEBREW POINT JUDEO-SPANISH VARIKA FB1F-FB36 ID_DIS or FREE_PVAL HEBREW LIGATURE YIDDISH YOD YOD PATAH..HEBREW LETTER ZAYIN WITH DAGESH FB37 UNASSIGNED <RESERVED> FB38-FB3C ID_DIS or FREE_PVAL HEBREW LETTER TET WITH DAGESH..HEBREW LETTER LAMED WITH DAGESH FB3D UNASSIGNED <RESERVED> FB3E ID_DIS or FREE_PVAL HEBREW LETTER MEM WITH DAGESH FB3F UNASSIGNED <RESERVED> FB40-FB41 ID_DIS or FREE_PVAL HEBREW LETTER NUN WITH DAGESH..HEBREW LETTER SAMEKH WITH DAGESH FB42 UNASSIGNED <RESERVED> FB43-FB44 ID_DIS or FREE_PVAL HEBREW LETTER FINAL PE WITH DAGESH..HEBREW LETTER PE WITH DAGESH FB45 UNASSIGNED <RESERVED> FB46-FBC1 ID_DIS or FREE_PVAL HEBREW LETTER TSADI WITH DAGESH..ARABIC SYMBOL SMALL TAH BELOW FBC2-FBD2 UNASSIGNED <RESERVED>..<RESERVED> FBD3-FD3F ID_DIS or FREE_PVAL ARABIC LETTER NG ISOLATED FORM..ORNATE RIGHT PARENTHESIS FD40-FD4F UNASSIGNED <RESERVED>..<RESERVED> FD50-FD8F ID_DIS or FREE_PVAL ARABIC LIGATURE TEH WITH JEEM WITH MEEM INITIAL FORM..ARABIC LIGATURE MEEM WITH KHAH WITH MEEM INITIAL FORM FD90-FD91 UNASSIGNED <RESERVED>..<RESERVED> FD92-FDC7 ID_DIS or FREE_PVAL ARABIC LIGATURE MEEM WITH JEEM WITH KHAH INITIAL FORM..ARABIC LIGATURE NOON WITH JEEM WITH YEH FINAL FORM FDC8-FDCF UNASSIGNED <RESERVED>..<RESERVED> FDD0-FDEF DISALLOWED <NOT A CHARACTER>..<NOT A CHARACTER> FDF0-FDFD ID_DIS or FREE_PVAL ARABIC LIGATURE SALLA USED AS KORANIC STOP SIGN ISOLATED FORM..ARABIC LIGATURE BISMILLAH AR-RAHMAN AR-RAHEEM FDFE-FDFF UNASSIGNED <RESERVED>..<RESERVED> FE00-FE0F DISALLOWED VARIATION SELECTOR-1..VARIATION SELECTOR-16 FE10-FE19 ID_DIS or FREE_PVAL PRESENTATION FORM FOR VERTICAL COMMA..PRESENTATION FORM FOR VERTICAL HORIZONTAL ELLIPSIS FE1A-FE1F UNASSIGNED <RESERVED>..<RESERVED> FE20-FE26 PVALID COMBINING LIGATURE LEFT HALF..COMBINING CONJOINING MACRON FE27-FE2F UNASSIGNED <RESERVED>..<RESERVED> FE30-FE52 ID_DIS or FREE_PVAL PRESENTATION FORM FOR VERTICAL TWO DOT LEADER..SMALL FULL STOP FE53 UNASSIGNED <RESERVED> FE54-FE66 ID_DIS or FREE_PVAL SMALL SEMICOLON..SMALL EQUALS SIGN FE67 UNASSIGNED <RESERVED> FE68-FE6B ID_DIS or FREE_PVAL SMALL REVERSE SOLIDUS..SMALL COMMERCIAL AT FE6C-FE6F UNASSIGNED <RESERVED>..<RESERVED> FE70-FE72 ID_DIS or FREE_PVAL ARABIC FATHATAN ISOLATED FORM..ARABIC DAMMATAN ISOLATED FORM FE73 PVALID ARABIC TAIL FRAGMENT FE74 ID_DIS or FREE_PVAL ARABIC KASRATAN ISOLATED FORM FE75 UNASSIGNED <RESERVED> FE76-FEFC ID_DIS or FREE_PVAL ARABIC FATHA ISOLATED FORM..ARABIC LIGATURE LAM WITH ALEF FINAL FORM FEFD-FEFE UNASSIGNED <RESERVED>..<RESERVED> FEFF DISALLOWED ZERO WIDTH NO-BREAK SPACE FF00 UNASSIGNED <RESERVED> FF01-FF9F ID_DIS or FREE_PVAL FULLWIDTH EXCLAMATION MARK..HALFWIDTH KATAKANA SEMI-VOICED SOUND MARK FFA0 DISALLOWED HALFWIDTH HANGUL FILLER FFA1-FFBE ID_DIS or FREE_PVAL HALFWIDTH HANGUL LETTER KIYEOK..HALFWIDTH HANGUL LETTER HIEUH FFBF-FFC1 UNASSIGNED <RESERVED>..<RESERVED> FFC2-FFC7 ID_DIS or FREE_PVAL HALFWIDTH HANGUL LETTER A..HALFWIDTH HANGUL LETTER E FFC8-FFC9 UNASSIGNED <RESERVED>..<RESERVED> FFCA-FFCF ID_DIS or FREE_PVAL HALFWIDTH HANGUL LETTER YEO..HALFWIDTH HANGUL LETTER OE FFD0-FFD1 UNASSIGNED <RESERVED>..<RESERVED> FFD2-FFD7 ID_DIS or FREE_PVAL HALFWIDTH HANGUL LETTER YO..HALFWIDTH HANGUL LETTER YU FFD8-FFD9 UNASSIGNED <RESERVED>..<RESERVED> FFDA-FFDC ID_DIS or FREE_PVAL HALFWIDTH HANGUL LETTER EU..HALFWIDTH HANGUL LETTER I FFDD-FFDF UNASSIGNED <RESERVED>..<RESERVED> FFE0-FFE6 ID_DIS or FREE_PVAL FULLWIDTH CENT SIGN..FULLWIDTH WON SIGN FFE7 UNASSIGNED <RESERVED> FFE8-FFEE ID_DIS or FREE_PVAL HALFWIDTH FORMS LIGHT VERTICAL..HALFWIDTH WHITE CIRCLE FFEF-FFF8 UNASSIGNED <RESERVED>..<RESERVED> FFF9-FFFB DISALLOWED INTERLINEAR ANNOTATION ANCHOR..INTERLINEAR ANNOTATION TERMINATOR FFFC-FFFD ID_DIS or FREE_PVAL OBJECT REPLACEMENT CHARACTER..REPLACEMENT CHARACTER FFFE-FFFF DISALLOWED <NOT A CHARACTER>..<NOT A CHARACTER> 10000-1000B PVALID LINEAR B SYLLABLE B008 A..LINEAR B SYLLABLE B046 JE 1000C UNASSIGNED <RESERVED> 1000D-10026 PVALID LINEAR B SYLLABLE B036 JO..LINEAR B SYLLABLE B032 QO 10027 UNASSIGNED <RESERVED> 10028-1003A PVALID LINEAR B SYLLABLE B060 RA..LINEAR B SYLLABLE B042 WO 1003B UNASSIGNED <RESERVED> 1003C-1003D PVALID LINEAR B SYLLABLE B017 ZA..LINEAR B SYLLABLE B074 ZE 1003E UNASSIGNED <RESERVED> 1003F-1004D PVALID LINEAR B SYLLABLE B020 ZO..LINEAR B SYLLABLE B091 TWO 1004E-1004F UNASSIGNED <RESERVED>..<RESERVED> 10050-1005D PVALID LINEAR B SYMBOL B018..LINEAR B SYMBOL B089 1005E-1007F UNASSIGNED <RESERVED>..<RESERVED> 10080-100FA PVALID LINEAR B IDEOGRAM B100 MAN..LINEAR B IDEOGRAM VESSEL B305 100FB-100FF UNASSIGNED <RESERVED>..<RESERVED> 10100-10102 ID_DIS or FREE_PVAL AEGEAN WORD SEPARATOR LINE..AEGEAN CHECK MARK 10103-10106 UNASSIGNED <RESERVED>..<RESERVED> 10107-10133 ID_DIS or FREE_PVAL AEGEAN NUMBER ONE..AEGEAN NUMBER NINETY THOUSAND 10134-10136 UNASSIGNED <RESERVED>..<RESERVED> 10137-1018A ID_DIS or FREE_PVAL AEGEAN WEIGHT BASE UNIT..GREEK ZERO SIGN 1018B-1018F UNASSIGNED <RESERVED>..<RESERVED> 10190-1019B ID_DIS or FREE_PVAL ROMAN SEXTANS SIGN..ROMAN CENTURIAL SIGN 1019C-101CF UNASSIGNED <RESERVED>..<RESERVED> 101D0-101FC ID_DIS or FREE_PVAL PHAISTOS DISC SIGN PEDESTRIAN..PHAISTOS DISC SIGN WAVY BAND 101FD PVALID PHAISTOS DISC SIGN COMBINING OBLIQUE STROKE 101FE-1027F UNASSIGNED <RESERVED>..<RESERVED> 10280-1029C PVALID LYCIAN LETTER A..LYCIAN LETTER X 1029D-1029F UNASSIGNED <RESERVED>..<RESERVED> 102A0-102D0 PVALID CARIAN LETTER A..CARIAN LETTER UUU3 102D1-102FF UNASSIGNED <RESERVED>..<RESERVED> 10300-1031E PVALID OLD ITALIC LETTER A..OLD ITALIC LETTER UU 1031F UNASSIGNED <RESERVED> 10320-10323 ID_DIS or FREE_PVAL OLD ITALIC NUMERAL ONE..OLD ITALIC NUMERAL FIFTY 10324-1032F UNASSIGNED <RESERVED>..<RESERVED> 10330-10340 PVALID GOTHIC LETTER AHSA..GOTHIC LETTER PAIRTHRA 10341 ID_DIS or FREE_PVAL GOTHIC LETTER NINETY 10342-10349 PVALID GOTHIC LETTER RAIDA..GOTHIC LETTER OTHAL 1034A ID_DIS or FREE_PVAL GOTHIC LETTER NINE HUNDRED 1034B-1037F UNASSIGNED <RESERVED>..<RESERVED> 10380-1039D PVALID UGARITIC LETTER ALPA..UGARITIC LETTER SSU 1039E UNASSIGNED <RESERVED> 1039F ID_DIS or FREE_PVAL UGARITIC WORD DIVIDER 103A0-103C3 PVALID OLD PERSIAN SIGN A..OLD PERSIAN SIGN HA 103C4-103C7 UNASSIGNED <RESERVED>..<RESERVED> 103C8-103CF PVALID OLD PERSIAN SIGN AURAMAZDAA..OLD PERSIAN SIGN BUUMISH 103D0-103D5 ID_DIS or FREE_PVAL OLD PERSIAN WORD DIVIDER..OLD PERSIAN NUMBER HUNDRED 103D6-103FF UNASSIGNED <RESERVED>..<RESERVED> 10400-1049D PVALID DESERET CAPITAL LETTER LONG I..OSMANYA LETTER OO 1049E-1049F UNASSIGNED <RESERVED>..<RESERVED> 104A0-104A9 PVALID OSMANYA DIGIT ZERO..OSMANYA DIGIT NINE 104AA-107FF UNASSIGNED <RESERVED>..<RESERVED> 10800-10805 PVALID CYPRIOT SYLLABLE A..CYPRIOT SYLLABLE JA 10806-10807 UNASSIGNED <RESERVED>..<RESERVED> 10808 PVALID CYPRIOT SYLLABLE JO 10809 UNASSIGNED <RESERVED> 1080A-10835 PVALID CYPRIOT SYLLABLE KA..CYPRIOT SYLLABLE WO 10836 UNASSIGNED <RESERVED> 10837-10838 PVALID CYPRIOT SYLLABLE XA..CYPRIOT SYLLABLE XE 10839-1083B UNASSIGNED <RESERVED>..<RESERVED> 1083C PVALID CYPRIOT SYLLABLE ZA 1083D-1083E UNASSIGNED <RESERVED>..<RESERVED> 1083F-10855 PVALID CYPRIOT SYLLABLE ZO..IMPERIAL ARAMAIC LETTER TAW 10856 UNASSIGNED <RESERVED> 10857-1085F ID_DIS or FREE_PVAL IMPERIAL ARAMAIC SECTION SIGN..IMPERIAL ARAMAIC NUMBER TEN THOUSAND 10860-108FF UNASSIGNED <RESERVED>..<RESERVED> 10900-10915 PVALID PHOENICIAN LETTER ALF..PHOENICIAN LETTER TAU 10916-1091B ID_DIS or FREE_PVAL PHOENICIAN NUMBER ONE..PHOENICIAN NUMBER THREE 1091C-1091E UNASSIGNED <RESERVED>..<RESERVED> 1091F ID_DIS or FREE_PVAL PHOENICIAN WORD SEPARATOR 10920-10939 PVALID LYDIAN LETTER A..LYDIAN LETTER C 1093A-1093E UNASSIGNED <RESERVED>..<RESERVED> 1093F ID_DIS or FREE_PVAL LYDIAN TRIANGULAR MARK 10940-1097F UNASSIGNED <RESERVED>..<RESERVED> 10980-109B7 PVALID MEROITIC HIEROGLYPHIC LETTER A..MEROITIC CURSIVE LETTER DA 109B8-109BD UNASSIGNED <RESERVED>..<RESERVED> 109BE-109BF PVALID MEROITIC CURSIVE LOGOGRAM RMT..MEROITIC CURSIVE LOGOGRAM IMN 109C0-109FF UNASSIGNED <RESERVED>..<RESERVED> 10A00-10A03 PVALID KHAROSHTHI LETTER A..KHAROSHTHI VOWEL SIGN VOCALIC R 10A04 UNASSIGNED <RESERVED> 10A05-10A06 PVALID KHAROSHTHI VOWEL SIGN E..KHAROSHTHI VOWEL SIGN O 10A07-10A0B UNASSIGNED <RESERVED>..<RESERVED> 10A0C-10A13 PVALID KHAROSHTHI VOWEL LENGTH MARK..KHAROSHTHI LETTER GHA 10A14 UNASSIGNED <RESERVED> 10A15-10A17 PVALID KHAROSHTHI LETTER CA..KHAROSHTHI LETTER JA 10A18 UNASSIGNED <RESERVED> 10A19-10A33 PVALID KHAROSHTHI LETTER NYA..KHAROSHTHI LETTER TTTHA 10A34-10A37 UNASSIGNED <RESERVED>..<RESERVED> 10A38-10A3A PVALID KHAROSHTHI SIGN BAR ABOVE..KHAROSHTHI SIGN DOT BELOW 10A3B-10A3E UNASSIGNED <RESERVED>..<RESERVED> 10A3F PVALID KHAROSHTHI VIRAMA 10A40-10A47 ID_DIS or FREE_PVAL KHAROSHTHI DIGIT ONE..KHAROSHTHI NUMBER ONE THOUSAND 10A48-10A4F UNASSIGNED <RESERVED>..<RESERVED> 10A50-10A58 ID_DIS or FREE_PVAL KHAROSHTHI PUNCTUATION DOT..KHAROSHTHI PUNCTUATION LINES 10A59-10A5F UNASSIGNED <RESERVED>..<RESERVED> 10A60-10A7C PVALID OLD SOUTH ARABIAN LETTER HE..OLD SOUTH ARABIAN LETTER THETH 10A7D-10A7F ID_DIS or FREE_PVAL OLD SOUTH ARABIAN NUMBER ONE..OLD SOUTH ARABIAN NUMERIC INDICATOR 10A80-10AFF UNASSIGNED <RESERVED>..<RESERVED> 10B00-10B35 PVALID AVESTAN LETTER A..AVESTAN LETTER HE 10B36-10B38 UNASSIGNED <RESERVED>..<RESERVED> 10B39-10B3F ID_DIS or FREE_PVAL AVESTAN ABBREVIATION MARK..LARGE ONE RING OVER TWO RINGS PUNCTUATION 10B40-10B55 PVALID INSCRIPTIONAL PARTHIAN LETTER ALEPH..INSCRIPTIONAL PARTHIAN LETTER TAW 10B56-10B57 UNASSIGNED <RESERVED>..<RESERVED> 10B58-10B5F ID_DIS or FREE_PVAL INSCRIPTIONAL PARTHIAN NUMBER ONE..INSCRIPTIONAL PARTHIAN NUMBER ONE THOUSAND 10B60-10B72 PVALID INSCRIPTIONAL PAHLAVI LETTER ALEPH..INSCRIPTIONAL PAHLAVI LETTER TAW 10B73-10B77 UNASSIGNED <RESERVED>..<RESERVED> 10B78-10B7F ID_DIS or FREE_PVAL INSCRIPTIONAL PAHLAVI NUMBER ONE..INSCRIPTIONAL PAHLAVI NUMBER ONE THOUSAND 10B80-10BFF UNASSIGNED <RESERVED>..<RESERVED> 10C00-10C48 PVALID OLD TURKIC LETTER ORKHON A..OLD TURKIC LETTER ORKHON BASH 10C49-10E5F UNASSIGNED <RESERVED>..<RESERVED> 10E60-10E7E ID_DIS or FREE_PVAL RUMI DIGIT ONE..RUMI FRACTION TWO THIRDS 10E7F-10FFF UNASSIGNED <RESERVED>..<RESERVED> 11000-11046 PVALID BRAHMI SIGN CANDRABINDU..BRAHMI VIRAMA 11047-1104D ID_DIS or FREE_PVAL BRAHMI DANDA..BRAHMI PUNCTUATION LOTUS 1104E-11051 UNASSIGNED <RESERVED>..<RESERVED> 11052-11065 ID_DIS or FREE_PVAL BRAHMI NUMBER ONE..BRAHMI NUMBER ONE THOUSAND 11066-1106F PVALID BRAHMI DIGIT ZERO..BRAHMI DIGIT NINE 11070-1107F UNASSIGNED <RESERVED>..<RESERVED> 11080-110BA PVALID KAITHI SIGN CANDRABINDU..KAITHI SIGN NUKTA 110BB-110BC ID_DIS or FREE_PVAL KAITHI ABBREVIATION SIGN..KAITHI ENUMERATION SIGN 110BD DISALLOWED KAITHI NUMBER SIGN 110BE-110C1 ID_DIS or FREE_PVAL KAITHI SECTION MARK..KAITHI DOUBLE DANDA 110C2-110CF UNASSIGNED <RESERVED>..<RESERVED> 110D0-110E8 PVALID SORA SOMPENG LETTER SAH..SORA SOMPENG LETTER MAE 110E9-110EF UNASSIGNED <RESERVED>..<RESERVED> 110F0-110F9 PVALID SORA SOMPENG DIGIT ZERO..SORA SOMPENG DIGIT NINE 110FA-110FF UNASSIGNED <RESERVED>..<RESERVED> 11100-11134 PVALID CHAKMA SIGN CANDRABINDU..CHAKMA MAAYYAA 11135 UNASSIGNED <RESERVED> 11136-1113F PVALID CHAKMA DIGIT ZERO..CHAKMA DIGIT NINE 11140-11143 ID_DIS or FREE_PVAL CHAKMA SECTION MARK..CHAKMA QUESTION MARK 11144-1117F UNASSIGNED <RESERVED>..<RESERVED> 11180-111C4 PVALID SHARADA SIGN CANDRABINDU..SHARADA OM 111C5-111C8 ID_DIS or FREE_PVAL SHARADA DANDA..SHARADA SEPARATOR 111C9-111CF UNASSIGNED <RESERVED>..<RESERVED> 111D0-111D9 PVALID SHARADA DIGIT ZERO..SHARADA DIGIT NINE 111DA-1167F UNASSIGNED <RESERVED>..<RESERVED> 11680-116B7 PVALID TAKRI LETTER A..TAKRI SIGN NUKTA 116B8-116BF UNASSIGNED <RESERVED>..<RESERVED> 116C0-116C9 PVALID TAKRI DIGIT ZERO..TAKRI DIGIT NINE 116CA-11FFF UNASSIGNED <RESERVED>..<RESERVED> 12000-1236E PVALID CUNEIFORM SIGN A..CUNEIFORM SIGN ZUM 1236F-123FF UNASSIGNED <RESERVED>..<RESERVED> 12400-12462 ID_DIS or FREE_PVAL CUNEIFORM NUMERIC SIGN TWO ASH..CUNEIFORM NUMERIC SIGN OLD ASSYRIAN ONE QUARTER 12463-1246F UNASSIGNED <RESERVED>..<RESERVED> 12470-12473 ID_DIS or FREE_PVAL CUNEIFORM PUNCTUATION SIGN OLD ASSYRIAN WORD DIVIDER..CUNEIFORM PUNCTUATION SIGN DIAGONAL TRICOLON 12474-12FFF UNASSIGNED <RESERVED>..<RESERVED> 13000-1342E PVALID EGYPTIAN HIEROGLYPH A001..EGYPTIAN HIEROGLYPH AA032 1342F-167FF UNASSIGNED <RESERVED>..<RESERVED> 16800-16A38 PVALID BAMUM LETTER PHASE-A NGKUE MFON..BAMUM LETTER PHASE-F VUEQ 16A39-16EFF UNASSIGNED <RESERVED>..<RESERVED> 16F00-16F44 PVALID MIAO LETTER PA..MIAO LETTER HHA 16F45-16F4F UNASSIGNED <RESERVED>..<RESERVED> 16F50-16F7E PVALID MIAO LETTER NASALIZATION..MIAO VOWEL SIGN NG 16F7F-16F8E UNASSIGNED <RESERVED>..<RESERVED> 16F8F-16F9F PVALID MIAO TONE RIGHT..MIAO LETTER REFORMED TONE-8 16FA0-1AFFF UNASSIGNED <RESERVED>..<RESERVED> 1B000-1B001 PVALID KATAKANA LETTER ARCHAIC E..HIRAGANA LETTER ARCHAIC YE 1B002-1CFFF UNASSIGNED <RESERVED>..<RESERVED> 1D000-1D0F5 ID_DIS or FREE_PVAL BYZANTINE MUSICAL SYMBOL PSILI..BYZANTINE MUSICAL SYMBOL GORGON NEO KATO 1D0F6-1D0FF UNASSIGNED <RESERVED>..<RESERVED> 1D100-1D126 ID_DIS or FREE_PVAL MUSICAL SYMBOL SINGLE BARLINE..MUSICAL SYMBOL DRUM CLEF-2 1D127-1D128 UNASSIGNED <RESERVED>..<RESERVED> 1D129-1D164 ID_DIS or FREE_PVAL MUSICAL SYMBOL MULTIPLE MEASURE REST..MUSICAL SYMBOL ONE HUNDRED TWENTY-EIGHTH NOTE 1D165-1D169 PVALID MUSICAL SYMBOL COMBINING STEM..MUSICAL SYMBOL COMBINING TREMOLO-3 1D16A-1D16C ID_DIS or FREE_PVAL MUSICAL SYMBOL FINGERED TREMOLO-1..MUSICAL SYMBOL FINGERED TREMOLO-3 1D16D-1D172 PVALID MUSICAL SYMBOL COMBINING AUGMENTATION DOT..MUSICAL SYMBOL COMBINING FLAG-5 1D173-1D17A DISALLOWED MUSICAL SYMBOL BEGIN BEAM..MUSICAL SYMBOL END PHRASE 1D17B-1D182 PVALID MUSICAL SYMBOL COMBINING ACCENT..MUSICAL SYMBOL COMBINING LOURE 1D183-1D184 ID_DIS or FREE_PVAL MUSICAL SYMBOL ARPEGGIATO UP..MUSICAL SYMBOL ARPEGGIATO DOWN 1D185-1D18B PVALID MUSICAL SYMBOL COMBINING DOIT..MUSICAL SYMBOL COMBINING TRIPLE TONGUE 1D18C-1D1A9 ID_DIS or FREE_PVAL MUSICAL SYMBOL RINFORZANDO..MUSICAL SYMBOL DEGREE SLASH 1D1AA-1D1AD PVALID MUSICAL SYMBOL COMBINING DOWN BOW..MUSICAL SYMBOL COMBINING SNAP PIZZICATO 1D1AE-1D1DD ID_DIS or FREE_PVAL MUSICAL SYMBOL PEDAL MARK..MUSICAL SYMBOL PES SUBPUNCTIS 1D1DE-1D1FF UNASSIGNED <RESERVED>..<RESERVED> 1D200-1D241 ID_DIS or FREE_PVAL GREEK VOCAL NOTATION SYMBOL-1..GREEK INSTRUMENTAL NOTATION SYMBOL-54 1D242-1D244 PVALID COMBINING GREEK MUSICAL TRISEME..COMBINING GREEK MUSICAL PENTASEME 1D245 ID_DIS or FREE_PVAL GREEK MUSICAL LEIMMA 1D246-1D2FF UNASSIGNED <RESERVED>..<RESERVED> 1D300-1D356 ID_DIS or FREE_PVAL MONOGRAM FOR EARTH..TETRAGRAM FOR FOSTERING 1D357-1D35F UNASSIGNED <RESERVED>..<RESERVED> 1D360-1D371 ID_DIS or FREE_PVAL COUNTING ROD UNIT DIGIT ONE..COUNTING ROD TENS DIGIT NINE 1D372-1D3FF UNASSIGNED <RESERVED>..<RESERVED> 1D400-1D454 ID_DIS or FREE_PVAL MATHEMATICAL BOLD CAPITAL A..MATHEMATICAL ITALIC SMALL G 1D455 UNASSIGNED <RESERVED> 1D456-1D49C ID_DIS or FREE_PVAL MATHEMATICAL ITALIC SMALL I..MATHEMATICAL SCRIPT CAPITAL A 1D49D UNASSIGNED <RESERVED> 1D49E-1D49F ID_DIS or FREE_PVAL MATHEMATICAL SCRIPT CAPITAL C..MATHEMATICAL SCRIPT CAPITAL D 1D4A0-1D4A1 UNASSIGNED <RESERVED>..<RESERVED> 1D4A2 ID_DIS or FREE_PVAL MATHEMATICAL SCRIPT CAPITAL G 1D4A3-1D4A4 UNASSIGNED <RESERVED>..<RESERVED> 1D4A5-1D4A6 ID_DIS or FREE_PVAL MATHEMATICAL SCRIPT CAPITAL J..MATHEMATICAL SCRIPT CAPITAL K 1D4A7-1D4A8 UNASSIGNED <RESERVED>..<RESERVED> 1D4A9-1D4AC ID_DIS or FREE_PVAL MATHEMATICAL SCRIPT CAPITAL N..MATHEMATICAL SCRIPT CAPITAL Q 1D4AD UNASSIGNED <RESERVED> 1D4AE-1D4B9 ID_DIS or FREE_PVAL MATHEMATICAL SCRIPT CAPITAL S..MATHEMATICAL SCRIPT SMALL D 1D4BA UNASSIGNED <RESERVED> 1D4BB ID_DIS or FREE_PVAL MATHEMATICAL SCRIPT SMALL F 1D4BC UNASSIGNED <RESERVED> 1D4BD-1D4C3 ID_DIS or FREE_PVAL MATHEMATICAL SCRIPT SMALL H..MATHEMATICAL SCRIPT SMALL N 1D4C4 UNASSIGNED <RESERVED> 1D4C5-1D505 ID_DIS or FREE_PVAL MATHEMATICAL SCRIPT SMALL P..MATHEMATICAL FRAKTUR CAPITAL B 1D506 UNASSIGNED <RESERVED> 1D507-1D50A ID_DIS or FREE_PVAL MATHEMATICAL FRAKTUR CAPITAL D..MATHEMATICAL FRAKTUR CAPITAL G 1D50B-1D50C UNASSIGNED <RESERVED>..<RESERVED> 1D50D-1D514 ID_DIS or FREE_PVAL MATHEMATICAL FRAKTUR CAPITAL J..MATHEMATICAL FRAKTUR CAPITAL Q 1D515 UNASSIGNED <RESERVED> 1D516-1D51C ID_DIS or FREE_PVAL MATHEMATICAL FRAKTUR CAPITAL S..MATHEMATICAL FRAKTUR CAPITAL Y 1D51D UNASSIGNED <RESERVED> 1D51E-1D539 ID_DIS or FREE_PVAL MATHEMATICAL FRAKTUR SMALL A..MATHEMATICAL DOUBLE-STRUCK CAPITAL B 1D53A UNASSIGNED <RESERVED> 1D53B-1D53E ID_DIS or FREE_PVAL MATHEMATICAL DOUBLE-STRUCK CAPITAL D..MATHEMATICAL DOUBLE-STRUCK CAPITAL G 1D53F UNASSIGNED <RESERVED> 1D540-1D544 ID_DIS or FREE_PVAL MATHEMATICAL DOUBLE-STRUCK CAPITAL I..MATHEMATICAL DOUBLE-STRUCK CAPITAL M 1D545 UNASSIGNED <RESERVED> 1D546 ID_DIS or FREE_PVAL MATHEMATICAL DOUBLE-STRUCK CAPITAL O 1D547-1D549 UNASSIGNED <RESERVED>..<RESERVED> 1D54A-1D550 ID_DIS or FREE_PVAL MATHEMATICAL DOUBLE-STRUCK CAPITAL S..MATHEMATICAL DOUBLE-STRUCK CAPITAL Y 1D551 UNASSIGNED <RESERVED> 1D552-1D6A5 ID_DIS or FREE_PVAL MATHEMATICAL DOUBLE-STRUCK SMALL A..MATHEMATICAL ITALIC SMALL DOTLESS J 1D6A6-1D6A7 UNASSIGNED <RESERVED>..<RESERVED> 1D6A8-1D7CB ID_DIS or FREE_PVAL MATHEMATICAL BOLD CAPITAL ALPHA..MATHEMATICAL BOLD SMALL DIGAMMA 1D7CC-1D7CD UNASSIGNED <RESERVED>..<RESERVED> 1D7CE-1D7FF ID_DIS or FREE_PVAL MATHEMATICAL BOLD DIGIT ZERO..MATHEMATICAL MONOSPACE DIGIT NINE 1D800-1EDFF UNASSIGNED <RESERVED>..<RESERVED> 1EE00-1EE03 ID_DIS or FREE_PVAL ARABIC MATHEMATICAL ALEF..ARABIC MATHEMATICAL DAL 1EE04 UNASSIGNED <RESERVED> 1EE05-1EE1F ID_DIS or FREE_PVAL ARABIC MATHEMATICAL WAW..ARABIC MATHEMATICAL DOTLESS QAF 1EE20 UNASSIGNED <RESERVED> 1EE21-1EE22 ID_DIS or FREE_PVAL ARABIC MATHEMATICAL INITIAL BEH..ARABIC MATHEMATICAL INITIAL JEEM 1EE23 UNASSIGNED <RESERVED> 1EE24 ID_DIS or FREE_PVAL ARABIC MATHEMATICAL INITIAL HEH 1EE25-1EE26 UNASSIGNED <RESERVED>..<RESERVED> 1EE27 ID_DIS or FREE_PVAL ARABIC MATHEMATICAL INITIAL HAH 1EE28 UNASSIGNED <RESERVED> 1EE29-1EE32 ID_DIS or FREE_PVAL ARABIC MATHEMATICAL INITIAL YEH..ARABIC MATHEMATICAL INITIAL QAF 1EE33 UNASSIGNED <RESERVED> 1EE34-1EE37 ID_DIS or FREE_PVAL ARABIC MATHEMATICAL INITIAL SHEEN..ARABIC MATHEMATICAL INITIAL KHAH 1EE38 UNASSIGNED <RESERVED> 1EE39 ID_DIS or FREE_PVAL ARABIC MATHEMATICAL INITIAL DAD 1EE3A UNASSIGNED <RESERVED> 1EE3B ID_DIS or FREE_PVAL ARABIC MATHEMATICAL INITIAL GHAIN 1EE3C-1EE41 UNASSIGNED <RESERVED>..<RESERVED> 1EE42 ID_DIS or FREE_PVAL ARABIC MATHEMATICAL TAILED JEEM 1EE43-1EE46 UNASSIGNED <RESERVED>..<RESERVED> 1EE47 ID_DIS or FREE_PVAL ARABIC MATHEMATICAL TAILED HAH 1EE48 UNASSIGNED <RESERVED> 1EE49 ID_DIS or FREE_PVAL ARABIC MATHEMATICAL TAILED YEH 1EE4A UNASSIGNED <RESERVED> 1EE4B ID_DIS or FREE_PVAL ARABIC MATHEMATICAL TAILED LAM 1EE4C UNASSIGNED <RESERVED> 1EE4D-1EE4F ID_DIS or FREE_PVAL ARABIC MATHEMATICAL TAILED NOON..ARABIC MATHEMATICAL TAILED AIN 1EE50 UNASSIGNED <RESERVED> 1EE51-1EE52 ID_DIS or FREE_PVAL ARABIC MATHEMATICAL TAILED SAD..ARABIC MATHEMATICAL TAILED QAF 1EE53 UNASSIGNED <RESERVED> 1EE54 ID_DIS or FREE_PVAL ARABIC MATHEMATICAL TAILED SHEEN 1EE55-1EE56 UNASSIGNED <RESERVED>..<RESERVED> 1EE57 ID_DIS or FREE_PVAL ARABIC MATHEMATICAL TAILED KHAH 1EE58 UNASSIGNED <RESERVED> 1EE59 ID_DIS or FREE_PVAL ARABIC MATHEMATICAL TAILED DAD 1EE5A UNASSIGNED <RESERVED> 1EE5B ID_DIS or FREE_PVAL ARABIC MATHEMATICAL TAILED GHAIN 1EE5C UNASSIGNED <RESERVED> 1EE5D ID_DIS or FREE_PVAL ARABIC MATHEMATICAL TAILED DOTLESS NOON 1EE5E UNASSIGNED <RESERVED> 1EE5F ID_DIS or FREE_PVAL ARABIC MATHEMATICAL TAILED DOTLESS QAF 1EE60 UNASSIGNED <RESERVED> 1EE61-1EE62 ID_DIS or FREE_PVAL ARABIC MATHEMATICAL STRETCHED BEH..ARABIC MATHEMATICAL STRETCHED JEEM 1EE63 UNASSIGNED <RESERVED> 1EE64 ID_DIS or FREE_PVAL ARABIC MATHEMATICAL STRETCHED HEH 1EE65-1EE66 UNASSIGNED <RESERVED>..<RESERVED> 1EE67-1EE6A ID_DIS or FREE_PVAL ARABIC MATHEMATICAL STRETCHED HAH..ARABIC MATHEMATICAL STRETCHED KAF 1EE6B UNASSIGNED <RESERVED> 1EE6C-1EE72 ID_DIS or FREE_PVAL ARABIC MATHEMATICAL STRETCHED MEEM..ARABIC MATHEMATICAL STRETCHED QAF 1EE73 UNASSIGNED <RESERVED> 1EE74-1EE77 ID_DIS or FREE_PVAL ARABIC MATHEMATICAL STRETCHED SHEEN..ARABIC MATHEMATICAL STRETCHED KHAH 1EE78 UNASSIGNED <RESERVED> 1EE79-1EE7C ID_DIS or FREE_PVAL ARABIC MATHEMATICAL STRETCHED DAD..ARABIC MATHEMATICAL STRETCHED DOTLESS BEH 1EE7D UNASSIGNED <RESERVED> 1EE7E ID_DIS or FREE_PVAL ARABIC MATHEMATICAL STRETCHED DOTLESS FEH 1EE7F UNASSIGNED <RESERVED> 1EE80-1EE89 ID_DIS or FREE_PVAL ARABIC MATHEMATICAL LOOPED ALEF..ARABIC MATHEMATICAL LOOPED YEH 1EE8A UNASSIGNED <RESERVED> 1EE8B-1EE9B ID_DIS or FREE_PVAL ARABIC MATHEMATICAL LOOPED LAM..ARABIC MATHEMATICAL LOOPED GHAIN 1EE9C-1EEA0 UNASSIGNED <RESERVED>..<RESERVED> 1EEA1-1EEA3 ID_DIS or FREE_PVAL ARABIC MATHEMATICAL DOUBLE-STRUCK BEH..ARABIC MATHEMATICAL DOUBLE-STRUCK DAL 1EEA4 UNASSIGNED <RESERVED> 1EEA5-1EEA9 ID_DIS or FREE_PVAL ARABIC MATHEMATICAL DOUBLE-STRUCK WAW..ARABIC MATHEMATICAL DOUBLE-STRUCK YEH 1EEAA UNASSIGNED <RESERVED> 1EEAB-1EEBB ID_DIS or FREE_PVAL ARABIC MATHEMATICAL DOUBLE-STRUCK LAM..ARABIC MATHEMATICAL DOUBLE-STRUCK GHAIN 1EEBC-1EEEF UNASSIGNED <RESERVED>..<RESERVED> 1EEF0-1EEF1 ID_DIS or FREE_PVAL ARABIC MATHEMATICAL OPERATOR MEEM WITH HAH WITH TATWEEL..ARABIC MATHEMATICAL OPERATOR HAH WITH DAL 1EEF2-1EFFF UNASSIGNED <RESERVED>..<RESERVED> 1F000-1F02B ID_DIS or FREE_PVAL MAHJONG TILE EAST WIND..MAHJONG TILE BACK 1F02C-1F02F UNASSIGNED <RESERVED>..<RESERVED> 1F030-1F093 ID_DIS or FREE_PVAL DOMINO TILE HORIZONTAL BACK..DOMINO TILE VERTICAL-06-06 1F094-1F09F UNASSIGNED <RESERVED>..<RESERVED> 1F0A0-1F0AE ID_DIS or FREE_PVAL PLAYING CARD BACK..PLAYING CARD KING OF SPADES 1F0AF-1F0B0 UNASSIGNED <RESERVED>..<RESERVED> 1F0B1-1F0BE ID_DIS or FREE_PVAL PLAYING CARD ACE OF HEARTS..PLAYING CARD KING OF HEARTS 1F0BF-1F0C0 UNASSIGNED <RESERVED>..<RESERVED> 1F0C1-1F0CF ID_DIS or FREE_PVAL PLAYING CARD ACE OF DIAMONDS..PLAYING CARD BLACK JOKER 1F0D0 UNASSIGNED <RESERVED> 1F0D1-1F0DF ID_DIS or FREE_PVAL PLAYING CARD ACE OF CLUBS..PLAYING CARD WHITE JOKER 1F0E0-1F0FF UNASSIGNED <RESERVED>..<RESERVED> 1F100-1F10A ID_DIS or FREE_PVAL DIGIT ZERO FULL STOP..DIGIT NINE COMMA 1F10B-1F10F UNASSIGNED <RESERVED>..<RESERVED> 1F110-1F12E ID_DIS or FREE_PVAL PARENTHESIZED LATIN CAPITAL LETTER A..CIRCLED WZ 1F12F UNASSIGNED <RESERVED> 1F130-1F16B ID_DIS or FREE_PVAL SQUARED LATIN CAPITAL LETTER A..RAISED MD SIGN 1F16C-1F16F UNASSIGNED <RESERVED>..<RESERVED> 1F170-1F19A ID_DIS or FREE_PVAL NEGATIVE SQUARED LATIN CAPITAL LETTER A..SQUARED VS 1F19B-1F1E5 UNASSIGNED <RESERVED>..<RESERVED> 1F1E6-1F202 ID_DIS or FREE_PVAL REGIONAL INDICATOR SYMBOL LETTER A..SQUARED KATAKANA SA 1F203-1F20F UNASSIGNED <RESERVED>..<RESERVED> 1F210-1F23A ID_DIS or FREE_PVAL SQUARED CJK UNIFIED IDEOGRAPH-624B..SQUARED CJK UNIFIED IDEOGRAPH-55B6 1F23B-1F23F UNASSIGNED <RESERVED>..<RESERVED> 1F240-1F248 ID_DIS or FREE_PVAL TORTOISE SHELL BRACKETED CJK UNIFIED IDEOGRAPH-672C..TORTOISE SHELL BRACKETED CJK UNIFIED IDEOGRAPH-6557 1F249-1F24F UNASSIGNED <RESERVED>..<RESERVED> 1F250-1F251 ID_DIS or FREE_PVAL CIRCLED IDEOGRAPH ADVANTAGE..CIRCLED IDEOGRAPH ACCEPT 1F252-1F2FF UNASSIGNED <RESERVED>..<RESERVED> 1F300-1F320 ID_DIS or FREE_PVAL CYCLONE..SHOOTING STAR 1F321-1F32F UNASSIGNED <RESERVED>..<RESERVED> 1F330-1F335 ID_DIS or FREE_PVAL CHESTNUT..CACTUS 1F336 UNASSIGNED <RESERVED> 1F337-1F37C ID_DIS or FREE_PVAL TULIP..BABY BOTTLE 1F37D-1F37F UNASSIGNED <RESERVED>..<RESERVED> 1F380-1F393 ID_DIS or FREE_PVAL RIBBON..GRADUATION CAP 1F394-1F39F UNASSIGNED <RESERVED>..<RESERVED> 1F3A0-1F3C4 ID_DIS or FREE_PVAL CAROUSEL HORSE..SURFER 1F3C5 UNASSIGNED <RESERVED> 1F3C6-1F3CA ID_DIS or FREE_PVAL TROPHY..SWIMMER 1F3CB-1F3DF UNASSIGNED <RESERVED>..<RESERVED> 1F3E0-1F3F0 ID_DIS or FREE_PVAL HOUSE BUILDING..EUROPEAN CASTLE 1F3F1-1F3FF UNASSIGNED <RESERVED>..<RESERVED> 1F400-1F43E ID_DIS or FREE_PVAL RAT..PAW PRINTS 1F43F UNASSIGNED <RESERVED> 1F440 ID_DIS or FREE_PVAL EYES 1F441 UNASSIGNED <RESERVED> 1F442-1F4F7 ID_DIS or FREE_PVAL EAR..CAMERA 1F4F8 UNASSIGNED <RESERVED> 1F4F9-1F4FC ID_DIS or FREE_PVAL VIDEO CAMERA..VIDEOCASSETTE 1F4FD-1F4FF UNASSIGNED <RESERVED>..<RESERVED> 1F500-1F53D ID_DIS or FREE_PVAL TWISTED RIGHTWARDS ARROWS..DOWN-POINTING SMALL RED TRIANGLE 1F53E-1F53F UNASSIGNED <RESERVED>..<RESERVED> 1F540-1F543 ID_DIS or FREE_PVAL CIRCLED CROSS POMMEE..NOTCHED LEFT SEMICIRCLE WITH THREE DOTS 1F544-1F54F UNASSIGNED <RESERVED>..<RESERVED> 1F550-1F567 ID_DIS or FREE_PVAL CLOCK FACE ONE OCLOCK..CLOCK FACE TWELVE-THIRTY 1F568-1F5FA UNASSIGNED <RESERVED>..<RESERVED> 1F5FB-1F640 ID_DIS or FREE_PVAL MOUNT FUJI..WEARY CAT FACE 1F641-1F644 UNASSIGNED <RESERVED>..<RESERVED> 1F645-1F64F ID_DIS or FREE_PVAL FACE WITH NO GOOD GESTURE..PERSON WITH FOLDED HANDS 1F650-1F67F UNASSIGNED <RESERVED>..<RESERVED> 1F680-1F6C5 ID_DIS or FREE_PVAL ROCKET..LEFT LUGGAGE 1F6C6-1F6FF UNASSIGNED <RESERVED>..<RESERVED> 1F700-1F773 ID_DIS or FREE_PVAL ALCHEMICAL SYMBOL FOR QUINTESSENCE..ALCHEMICAL SYMBOL FOR HALF OUNCE 1F774-1FFFD UNASSIGNED <RESERVED>..<RESERVED> 1FFFE-1FFFF DISALLOWED <NOT A CHARACTER>..<NOT A CHARACTER> 20000-2A6D6 PVALID <CJK Ideograph Extension B>..<CJK Ideograph Extension B> 2A6D7-2A6FF UNASSIGNED <RESERVED>..<RESERVED> 2A700-2B734 PVALID <CJK Ideograph Extension C>..<CJK Ideograph Extension C> 2B735-2B73F UNASSIGNED <RESERVED>..<RESERVED> 2B740-2B81D PVALID <CJK Ideograph Extension D>..<CJK Ideograph Extension D> 2B81E-2F7FF UNASSIGNED <RESERVED>..<RESERVED> 2F800-2FA1D ID_DIS or FREE_PVAL CJK COMPATIBILITY IDEOGRAPH-2F800..CJK COMPATIBILITY IDEOGRAPH-2FA1D 2FA1E-2FFFD UNASSIGNED <RESERVED>..<RESERVED> 2FFFE-2FFFF DISALLOWED <NOT A CHARACTER>..<NOT A CHARACTER> 30000-3FFFD UNASSIGNED <RESERVED>..<RESERVED> 3FFFE-3FFFF DISALLOWED <NOT A CHARACTER>..<NOT A CHARACTER> 40000-4FFFD UNASSIGNED <RESERVED>..<RESERVED> 4FFFE-4FFFF DISALLOWED <NOT A CHARACTER>..<NOT A CHARACTER> 50000-5FFFD UNASSIGNED <RESERVED>..<RESERVED> 5FFFE-5FFFF DISALLOWED <NOT A CHARACTER>..<NOT A CHARACTER> 60000-6FFFD UNASSIGNED <RESERVED>..<RESERVED> 6FFFE-6FFFF DISALLOWED <NOT A CHARACTER>..<NOT A CHARACTER> 70000-7FFFD UNASSIGNED <RESERVED>..<RESERVED> 7FFFE-7FFFF DISALLOWED <NOT A CHARACTER>..<NOT A CHARACTER> 80000-8FFFD UNASSIGNED <RESERVED>..<RESERVED> 8FFFE-8FFFF DISALLOWED <NOT A CHARACTER>..<NOT A CHARACTER> 90000-9FFFD UNASSIGNED <RESERVED>..<RESERVED> 9FFFE-9FFFF DISALLOWED <NOT A CHARACTER>..<NOT A CHARACTER> A0000-AFFFD UNASSIGNED <RESERVED>..<RESERVED> AFFFE-AFFFF DISALLOWED <NOT A CHARACTER>..<NOT A CHARACTER> B0000-BFFFD UNASSIGNED <RESERVED>..<RESERVED> BFFFE-BFFFF DISALLOWED <NOT A CHARACTER>..<NOT A CHARACTER> C0000-CFFFD UNASSIGNED <RESERVED>..<RESERVED> CFFFE-CFFFF DISALLOWED <NOT A CHARACTER>..<NOT A CHARACTER> D0000-DFFFD UNASSIGNED <RESERVED>..<RESERVED> DFFFE-DFFFF DISALLOWED <NOT A CHARACTER>..<NOT A CHARACTER> E0000 UNASSIGNED <RESERVED> E0001 DISALLOWED LANGUAGE TAG E0002-E001F UNASSIGNED <RESERVED>..<RESERVED> E0020-E007F DISALLOWED TAG SPACE..CANCEL TAG E0080-E00FF UNASSIGNED <RESERVED>..<RESERVED> E0100-E01EF DISALLOWED VARIATION SELECTOR-17..VARIATION SELECTOR-256 E01F0-EFFFD UNASSIGNED <RESERVED>..<RESERVED> EFFFE-10FFFF DISALLOWED <NOT A CHARACTER>..<NOT A CHARACTER> --Apple-Mail=_77AEEF8F-5339-4E07-9F84-DB760FC54733 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=iso-8859-1 --Apple-Mail=_77AEEF8F-5339-4E07-9F84-DB760FC54733-- --Apple-Mail=_6F46D468-5080-43E6-B4B2-075CE3809C32 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 iQEcBAEBAgAGBQJR9iw1AAoJEJk7o/xhVanarSwIAL7RJ7g20ExRxL6sWFMJuw6w hSyIp1vDaP6q21zzKa5TOAc0aX9G6ZzBVLmGtw0sZMTLb16iTfET+icR415URld3 0m3hllOCqDVuFTX08zjyJfEg5OMhP7Qi3KwfZ8zF0W6wczK5wp5EJw5bs1VnqpxB IdkvHuQHC8440CxjFkenQZ0xBKME4Q6vhF0jlQscP8iodArdah+976+DBj5UwspI gOASNec70V5/eXL/GbDMlfFPBq69xLzMolpyn/lWUImJ3y0Yoca2tSSdysGjfZXI U8bIw6Jy7lOfzWoQB4KYOCpdqSlw0vUtXrJVGp5llvRxgBvowI8vlp3uLdQ5j/A= =2jvO -----END PGP SIGNATURE----- --Apple-Mail=_6F46D468-5080-43E6-B4B2-075CE3809C32--