From nobody Mon Sep 1 04:26:41 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D9841A0396 for ; Mon, 1 Sep 2014 04:26:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.241 X-Spam-Level: ** X-Spam-Status: No, score=2.241 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.668] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id llbZhfluAhai for ; Mon, 1 Sep 2014 04:26:37 -0700 (PDT) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id 1C98D1A039A for ; Mon, 1 Sep 2014 04:26:36 -0700 (PDT) Received: from scmeg01-14.scbb.aoyama.ac.jp (scmse.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id 7F6A232E56D; Mon, 1 Sep 2014 20:25:51 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 38b0_9da8_d60dd34c_0db9_429f_b8db_cde5fdec0a07; Mon, 01 Sep 2014 20:25:50 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 81B68C0008; Mon, 1 Sep 2014 20:25:50 +0900 (JST) Message-ID: <540457B0.1070102@it.aoyama.ac.jp> Date: Mon, 01 Sep 2014 20:25:36 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Peter Saint-Andre , "Joe Hildebrand (jhildebr)" , "precis@ietf.org" References: <5400D762.2000602@stpeter.im> In-Reply-To: <5400D762.2000602@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/precis/M17sexYLtY9VeOPMl3D4YXocyzg Subject: Re: [precis] U+1E9B X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 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 Sep 2014 11:26:38 -0000 On 2014/08/30 04:41, Peter Saint-Andre wrote: > This brings up another point: it probably makes sense to delete the > codepoint table from the precis-framework specification and to create > the initial registration in a better way (see discussion in other > threads). It was helpful scaffolding, but probably has outlived its > usefulness. One alternative is to have two separate drafts, the actual framework and the data tables. That's what the LTRU WG used for language subtags, in two iterations. Just an idea. Regards, Martin. From nobody Mon Sep 1 04:54:17 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 467111A0295 for ; Mon, 1 Sep 2014 04:54:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.241 X-Spam-Level: ** X-Spam-Status: No, score=2.241 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.668] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PnZsqKG6bktw for ; Mon, 1 Sep 2014 04:54:14 -0700 (PDT) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id B05C71A026E for ; Mon, 1 Sep 2014 04:54:13 -0700 (PDT) Received: from scmeg01-14.scbb.aoyama.ac.jp (scmeg01-14.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id 2165232E53C; Mon, 1 Sep 2014 20:53:29 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 38b0_acf5_29304bc5_c595_4513_aa97_40b2888af190; Mon, 01 Sep 2014 20:53:29 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 13E03BF4E2; Mon, 1 Sep 2014 20:53:28 +0900 (JST) Message-ID: <54045E29.8090103@it.aoyama.ac.jp> Date: Mon, 01 Sep 2014 20:53:13 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: John C Klensin , "Joe Hildebrand (jhildebr)" , Takahiro Nemoto , precis@ietf.org References: <96BB5F7A8B584612998969F2@JcK-HP8200.jck.com> <2C363036-165C-4BFF-A505-7097F46D71AF@cisco.com> <018E0736DCDA1E4C8CD084B4@JcK-HP8200.jck.com> In-Reply-To: <018E0736DCDA1E4C8CD084B4@JcK-HP8200.jck.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/precis/GBV8caeMJeWANjlTJ1cFETh8LQw Subject: Re: [precis] review of codepoint table in draft-ietf-precis-framework-17 X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 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 Sep 2014 11:54:15 -0000 On 2014/08/30 03:38, John C Klensin wrote: > (1) WHATEWG and W3C are charging ahead with an "Encoding" > specification that will apparently be normatively referenced > from HTML5. With luck, an update to/ replacement for the very > important "Charmod" spec will be right behind it. The > recommendations of those two documents are different from the > proposed PRECIS ones. One way of looking at those specs in the > PRECIS context is that they represent yet another profile and > that, if two or three (or more if IDNA is counted) are > acceptable, than one more doesn't make much difference. At the > other extreme, some people have taken the position about the W3C > Charmod and Encoding specs that the web, web browsers, web > applications, and web access to other protocols so dominates the > Internet that any conflicting specifications are irrelevant (or > various worse words). If the latter view is correct than the > PRECIS effort is, to a considerable degree, a waste of time and, > worse, a source of more confusion, at least for any protocol > that might be accessed via a URI or from a web page. My own > view is that reality lies somewhere between those positions, but > my ability to predict the near-term future is notoriously bad. I might be wrong, but I see no connection between the "Encoding" spec and PRECIS. "Encoding" is about codepoints (Unicode scalar values,...) <=> bytes, and that's below PRECIS. I also don't think that an update of the "Charmod" spec will be "right behind it". Actually, there are several parts to the "Charmod" spec, in different stages: Charmod Fundamentals (http://www.w3.org/TR/charmod/) is a Rec since 2005 and some parts of it are somewhat outdated (if one believes the "Encoding" spec, then e.g. http://www.w3.org/TR/charmod/#C020 would be outdated), but starting an update would be a major undertaking and there sure would be much better ways to spend I18N resources. Charmod Normalization (http://www.w3.org/TR/charmod-norm/, nowadays the subtitle is "String Matching and Searching") is in active but rather slow development, at Working Draft stage. It is probably the one most related to PRECIS. The differences are that A) it deals with both identifiers and content, whereas PRECIS deals with identifiers (or what they are called) only; and B) it (in one way or another over the timespan of way more than 10 years) only recommends NFC, whereas PRECIS provides further restrictions. Whether this part of Charmod will proceed "right behind" "Encoding" or not depends on the meaning of "right behind", but the above differences A and B have been around since these issues were first introduced into IDNA and Charmod drafts, so taking that as News of any kind would be very surprising. There isn't any fundamental conflict between IDNA/PRECIS and Charmod Normalization. Discussions about the specific versions of IDNA apart, browsers and other infrastructure in perfectly capable to use IDNA checks or conversions on the domain part of an URI/IRI/URL even if putting the rest of an URI/IRI/URL and the rest of a document is just recommended to be in NFC. Things would be different if Charmod Normalization suddenly started to recommend or require NFD or some such. Charmod Resource Identifiers (http://www.w3.org/TR/charmod-resid/) formally is in Candidate Recommendation since 2004, and that shows how little attention it got over the years, although the use of non-Unicode characters in Web addresses (use whatever acronym you want) is certainly a reality at least in some important contexts (such as HTML, XML, and RDF). Regards, Martin. From nobody Tue Sep 2 05:58:29 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 814661A030B for ; Tue, 2 Sep 2014 05:58:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.27 X-Spam-Level: X-Spam-Status: No, score=-2.27 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wuaeNN9fUwOn for ; Tue, 2 Sep 2014 05:58:26 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id CA6E11A031B for ; Tue, 2 Sep 2014 05:58:21 -0700 (PDT) Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A236441269; Tue, 2 Sep 2014 06:59:23 -0600 (MDT) Message-ID: <5405BEEB.3010604@stpeter.im> Date: Tue, 02 Sep 2014 06:58:19 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= , "Joe Hildebrand (jhildebr)" , "precis@ietf.org" References: <5400D762.2000602@stpeter.im> <540457B0.1070102@it.aoyama.ac.jp> In-Reply-To: <540457B0.1070102@it.aoyama.ac.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/precis/sFICbz8Xo0fUZ3i5N2hJ05A4ATk Subject: Re: [precis] U+1E9B X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 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 Sep 2014 12:58:27 -0000 On 9/1/14, 5:25 AM, "Martin J. Dürst" wrote: > On 2014/08/30 04:41, Peter Saint-Andre wrote: > >> This brings up another point: it probably makes sense to delete the >> codepoint table from the precis-framework specification and to create >> the initial registration in a better way (see discussion in other >> threads). It was helpful scaffolding, but probably has outlived its >> usefulness. > > One alternative is to have two separate drafts, the actual framework and > the data tables. That's what the LTRU WG used for language subtags, in > two iterations. Just an idea. Yes, I was thinking about moving the table to an informational draft for purposes of traceability. Peter From nobody Tue Sep 2 06:01:06 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 104991A0343 for ; Tue, 2 Sep 2014 06:01:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.27 X-Spam-Level: X-Spam-Status: No, score=-4.27 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BNxOqHY06Gno for ; Tue, 2 Sep 2014 06:00:59 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id E03711A0347 for ; Tue, 2 Sep 2014 06:00:53 -0700 (PDT) Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id CFDCB41269; Tue, 2 Sep 2014 07:01:55 -0600 (MDT) Message-ID: <5405BF83.1050201@stpeter.im> Date: Tue, 02 Sep 2014 07:00:51 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= , John Klensin References: <96BB5F7A8B584612998969F2@JcK-HP8200.jck.com> <2C363036-165C-4BFF-A505-7097F46D71AF@cisco.com> <018E0736DCDA1E4C8CD084B4@JcK-HP8200.jck.com> <5400E32E.8050309@stpeter.im> <4E4A22237D1D05417D61EC96@JcK-HP8200.jck.com> <29943805-D48F-4DF7-9E4E-5D3D8FBCBB31@frobbit.se> In-Reply-To: <29943805-D48F-4DF7-9E4E-5D3D8FBCBB31@frobbit.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/precis/I-K20zVgnngyJvKP8lNE11Inzts Cc: precis@ietf.org Subject: Re: [precis] review of codepoint table in draft-ietf-precis-framework-17 X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 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 Sep 2014 13:01:04 -0000 On 8/30/14, 12:41 AM, Patrik Fltstrm wrote: > > On 29 aug 2014, at 23:03, John C Klensin wrote: > >>> My interpretation is that sections 7.1-7.10 of the >>> precis-framework document will be changed to reference >>> sections 2.1-2.10 of RFC 5982, not copy text from RFC 5892. >>> >>> This gives us one set of rules ("A" through "J" from RFC 5892, >>> "K" through "R" for PRECIS). >> >> That definitely works for me. > > Sounds good, I think. Let me just check...do you imply that the referenced rule B from 5892 is in PRECIS still called B? Not that L in PRECIS is B in 5892? > > I think we should call the same rule the same letter in both standards, if you know what I mean. I think that is what you say, right? That has been the intent all along, but again if people think we haven't actualized that intent then let us know! Peter From nobody Tue Sep 2 08:46:52 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81F4A1A86F0 for ; Tue, 2 Sep 2014 08:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.869 X-Spam-Level: X-Spam-Status: No, score=-14.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IuMCHT8g0GcC for ; Tue, 2 Sep 2014 08:46:48 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A36881A871C for ; Tue, 2 Sep 2014 08:46:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=292; q=dns/txt; s=iport; t=1409672808; x=1410882408; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=XbExTs1a4Lo3PuBKKpwkl/Uxzydo+sOCpbcY4Wo2i8Y=; b=GTOnl/YTtt4jpUGUU0qey2tl/tqWZ4+75zZUrgAE0PHNYuan3FGkLbJC Ty4uukgoeX1aNy1EyJDMl6k0hWFprZTtcVZD/sXAm6UYUC7iHF7KmaDvR TvtgQ4Dxcu8ElhMIhVBtfLEMSCybMqNyn3ahZSrkIdIssWelIwA5e7bXq I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFAFPlBVStJA2F/2dsb2JhbABaDoJ/gSoEgnjMcQEZehZ3hAQBAQQjEVUCAQgaAiYCAgIwFRACBAESiEKmOZUqAReBLI1uOoJ5NoEdAQSRMYsrlR6DH0JsgUiBBwEBAQ X-IronPort-AV: E=Sophos;i="5.04,449,1406592000"; d="scan'208";a="74257131" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-6.cisco.com with ESMTP; 02 Sep 2014 15:46:47 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s82Fkl3i029270 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 2 Sep 2014 15:46:47 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.68]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0195.001; Tue, 2 Sep 2014 10:46:47 -0500 From: "Joe Hildebrand (jhildebr)" To: Peter Saint-Andre , =?utf-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= , "precis@ietf.org" Thread-Topic: [precis] U+1E9B Thread-Index: AQHPw8E3LJ5mcVjfiUWe4N4g8nsdtJvsezUAgAGsPYD//8qMAA== Date: Tue, 2 Sep 2014 15:46:46 +0000 Message-ID: References: <5400D762.2000602@stpeter.im> <540457B0.1070102@it.aoyama.ac.jp> <5405BEEB.3010604@stpeter.im> In-Reply-To: <5405BEEB.3010604@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/15.3.0.140730 x-originating-ip: [10.129.24.156] Content-Type: text/plain; charset="utf-8" Content-ID: <6A34F36CFA20DF4FA8ACFB8C570751DA@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/precis/q4RETDm8KdZt6kdpbyPrmgaUV8E Subject: Re: [precis] U+1E9B X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 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 Sep 2014 15:46:50 -0000 T24gOS8yLzE0LCAxMjo1OCBQTSwgIlBldGVyIFNhaW50LUFuZHJlIiA8c3RwZXRlckBzdHBldGVy LmltPiB3cm90ZToNCg0KPlllcywgSSB3YXMgdGhpbmtpbmcgYWJvdXQgbW92aW5nIHRoZSB0YWJs ZSB0byBhbiBpbmZvcm1hdGlvbmFsIGRyYWZ0IGZvciANCj5wdXJwb3NlcyBvZiB0cmFjZWFiaWxp dHkuDQoNCisxDQoNCi0tIA0KSm9lIEhpbGRlYnJhbmQNCg0KDQoNCg== From nobody Tue Sep 2 09:27:30 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 247AE1A0678 for ; Tue, 2 Sep 2014 09:27:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.869 X-Spam-Level: X-Spam-Status: No, score=-16.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id azq1VIOSimFR for ; Tue, 2 Sep 2014 09:27:25 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 437911A065E for ; Tue, 2 Sep 2014 09:27:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1586; q=dns/txt; s=iport; t=1409675245; x=1410884845; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=WBAhKfhSp/B/obGlDgK4fTyK2poZdG2NPdXBMb0m6sg=; b=fiYEBNwvqx1CeA1cVBOHhXTmw5jle2foVNZo1MXMntU/VKeI0zSGMMTd Bip4vzK/SiBXvPKGjRpMfzFj/t6kd5QpT9m9Qw1CQjsc/wsSAkxBEjYnH 9fbd+xJQ0iuQ3CCUazdiNmRGyl67bzc+eDKt9XSjG4aRKo0THLRd3Y860 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFAKDvBVStJA2M/2dsb2JhbABagw2BKgSCeMx2ARl6FneEBAEBBCMRRRACAQgYAgImAgICMBUQAgQBDQWIQqZGlSwBF4EsjW4zB4J5NoEdAQSRMYsrlR6DYWyBSIEHAQEB X-IronPort-AV: E=Sophos;i="5.04,450,1406592000"; d="scan'208";a="74222036" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-1.cisco.com with ESMTP; 02 Sep 2014 16:27:24 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s82GROrQ011563 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 2 Sep 2014 16:27:24 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.68]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0195.001; Tue, 2 Sep 2014 11:27:24 -0500 From: "Joe Hildebrand (jhildebr)" To: Peter Saint-Andre , =?utf-8?B?UGF0cmlrIEbDpGx0c3Ryw7Zt?= , John Klensin Thread-Topic: [precis] review of codepoint table in draft-ietf-precis-framework-17 Thread-Index: AQHPwtCzUXM0y4hYL0C2DuBUsW/wX5vmchEAgAFNUACAAH/CAIAAH4kAgAAJAICAAKFTgIAFIQmA///VLwA= Date: Tue, 2 Sep 2014 16:27:23 +0000 Message-ID: References: <96BB5F7A8B584612998969F2@JcK-HP8200.jck.com> <2C363036-165C-4BFF-A505-7097F46D71AF@cisco.com> <018E0736DCDA1E4C8CD084B4@JcK-HP8200.jck.com> <5400E32E.8050309@stpeter.im> <4E4A22237D1D05417D61EC96@JcK-HP8200.jck.com> <29943805-D48F-4DF7-9E4E-5D3D8FBCBB31@frobbit.se> <5405BF83.1050201@stpeter.im> In-Reply-To: <5405BF83.1050201@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/15.3.0.140730 x-originating-ip: [10.129.24.156] Content-Type: text/plain; charset="utf-8" Content-ID: <5440A0D2D3DA3C4CA34CB8DF820869E3@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/precis/dWLzlj7RDKxCWCeTobyeHWf_BWw Cc: "precis@ietf.org" Subject: Re: [precis] review of codepoint table in draft-ietf-precis-framework-17 X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 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 Sep 2014 16:27:27 -0000 T24gOS8yLzE0LCAxOjAwIFBNLCAiUGV0ZXIgU2FpbnQtQW5kcmUiIDxzdHBldGVyQHN0cGV0ZXIu aW0+IHdyb3RlOg0KDQo+T24gOC8zMC8xNCwgMTI6NDEgQU0sIFBhdHJpayBGw6RsdHN0csO2bSB3 cm90ZToNCj4+DQo+PiBPbiAyOSBhdWcgMjAxNCwgYXQgMjM6MDMsIEpvaG4gQyBLbGVuc2luIDxq b2huLWlldGZAamNrLmNvbT4gd3JvdGU6DQo+Pg0KPj4+PiBNeSBpbnRlcnByZXRhdGlvbiBpcyB0 aGF0IHNlY3Rpb25zIDcuMS03LjEwIG9mIHRoZQ0KPj4+PiBwcmVjaXMtZnJhbWV3b3JrIGRvY3Vt ZW50IHdpbGwgYmUgY2hhbmdlZCB0byByZWZlcmVuY2UNCj4+Pj4gc2VjdGlvbnMgMi4xLTIuMTAg b2YgUkZDIDU5ODIsIG5vdCBjb3B5IHRleHQgZnJvbSBSRkMgNTg5Mi4NCj4+Pj4NCj4+Pj4gVGhp cyBnaXZlcyB1cyBvbmUgc2V0IG9mIHJ1bGVzICgiQSIgdGhyb3VnaCAiSiIgZnJvbSBSRkMgNTg5 MiwNCj4+Pj4gIksiIHRocm91Z2ggIlIiIGZvciBQUkVDSVMpLg0KPj4+DQo+Pj4gVGhhdCBkZWZp bml0ZWx5IHdvcmtzIGZvciBtZS4NCj4+DQo+PiBTb3VuZHMgZ29vZCwgSSB0aGluay4gTGV0IG1l IGp1c3QgY2hlY2suLi5kbyB5b3UgaW1wbHkgdGhhdCB0aGUgDQo+PnJlZmVyZW5jZWQgcnVsZSBC IGZyb20gNTg5MiBpcyBpbiBQUkVDSVMgc3RpbGwgY2FsbGVkIEI/IE5vdCB0aGF0IEwgaW4gDQo+ PlBSRUNJUyBpcyBCIGluIDU4OTI/DQo+Pg0KPj4gSSB0aGluayB3ZSBzaG91bGQgY2FsbCB0aGUg c2FtZSBydWxlIHRoZSBzYW1lIGxldHRlciBpbiBib3RoIHN0YW5kYXJkcywgDQo+PmlmIHlvdSBr bm93IHdoYXQgSSBtZWFuLiBJIHRoaW5rIHRoYXQgaXMgd2hhdCB5b3Ugc2F5LCByaWdodD8NCj4N Cj5UaGF0IGhhcyBiZWVuIHRoZSBpbnRlbnQgYWxsIGFsb25nLCBidXQgYWdhaW4gaWYgcGVvcGxl IHRoaW5rIHdlIGhhdmVuJ3QgDQo+YWN0dWFsaXplZCB0aGF0IGludGVudCB0aGVuIGxldCB1cyBr bm93IQ0KDQpJJ20gZmluZSB3aXRoIHRoaXMgYXBwcm9hY2ggYXMgd2VsbC4gIEkgd2FzIGdvaW5n IHRvIHN1Z2dlc3QgbW92aW5nIHRoZSANCnN0YXJ0IG9mIHRoZSBQUkVDSVMgYmxvY2sgdG8gIlAi LCBidXQgSSBkb24ndCB0aGluayBpdCdzIHdvcnRoIHRoZSBoYXNzbGUuDQoNCi0tIA0KSm9lIEhp bGRlYnJhbmQNCg0KDQoNCg== From nobody Tue Sep 2 09:30:29 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80F3F1A046C for ; Tue, 2 Sep 2014 09:30:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.27 X-Spam-Level: X-Spam-Status: No, score=-4.27 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wS479C78sr_2 for ; Tue, 2 Sep 2014 09:30:17 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 773121A0412 for ; Tue, 2 Sep 2014 09:30:17 -0700 (PDT) Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 57C9341269; Tue, 2 Sep 2014 10:31:20 -0600 (MDT) Message-ID: <5405F097.9020600@stpeter.im> Date: Tue, 02 Sep 2014 10:30:15 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Joe Hildebrand (jhildebr)" , =?UTF-8?B?UGF0cmlrIA==?= =?UTF-8?B?RsOkbHRzdHLDtm0=?= , John Klensin References: <96BB5F7A8B584612998969F2@JcK-HP8200.jck.com> <2C363036-165C-4BFF-A505-7097F46D71AF@cisco.com> <018E0736DCDA1E4C8CD084B4@JcK-HP8200.jck.com> <5400E32E.8050309@stpeter.im> <4E4A22237D1D05417D61EC96@JcK-HP8200.jck.com> <29943805-D48F-4DF7-9E4E-5D3D8FBCBB31@frobbit.se> <5405BF83.1050201@stpeter.im> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/precis/SJgT6j3jx8nqXLCU8yO7TJ_iUf4 Cc: "precis@ietf.org" Subject: Re: [precis] review of codepoint table in draft-ietf-precis-framework-17 X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 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 Sep 2014 16:30:19 -0000 On 9/2/14, 10:27 AM, Joe Hildebrand (jhildebr) wrote: > On 9/2/14, 1:00 PM, "Peter Saint-Andre" wrote: > >> On 8/30/14, 12:41 AM, Patrik Fältström wrote: >>> >>> On 29 aug 2014, at 23:03, John C Klensin wrote: >>> >>>>> My interpretation is that sections 7.1-7.10 of the >>>>> precis-framework document will be changed to reference >>>>> sections 2.1-2.10 of RFC 5982, not copy text from RFC 5892. >>>>> >>>>> This gives us one set of rules ("A" through "J" from RFC 5892, >>>>> "K" through "R" for PRECIS). >>>> >>>> That definitely works for me. >>> >>> Sounds good, I think. Let me just check...do you imply that the >>> referenced rule B from 5892 is in PRECIS still called B? Not that L in >>> PRECIS is B in 5892? >>> >>> I think we should call the same rule the same letter in both standards, >>> if you know what I mean. I think that is what you say, right? >> >> That has been the intent all along, but again if people think we haven't >> actualized that intent then let us know! > > I'm fine with this approach as well. I was going to suggest moving the > start of the PRECIS block to "P", but I don't think it's worth the hassle. Yeah but do we have a i26 problem when we run out of letters from the Latin alphabet? ;-) Peter From nobody Tue Sep 2 09:31:36 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6E9F1A045B for ; Tue, 2 Sep 2014 09:31:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.869 X-Spam-Level: X-Spam-Status: No, score=-16.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ToBHbOFgRejY for ; Tue, 2 Sep 2014 09:31:33 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5E3C1A0412 for ; Tue, 2 Sep 2014 09:31:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=568; q=dns/txt; s=iport; t=1409675495; x=1410885095; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=bXkBAeMT6YvkD4NVJcjFYXrws7E6VPasT2rzEJw+HCw=; b=GI+pkN6CNHDD853zzcGTUzcFiTv83753/Eqvo4+h0cgmV/ZxOlDBOzgk VPbNg2FcGNieufoGOkoZ9VlKZcrMSNJeFrUGl4lMpixZiv5X+pHejLeIf T5KfcmqNHGm/uWF7g2DhhcvPBPYlguCBsw70/vkXy7bydSDtDLslaAsFI I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFAB/wBVStJV2Y/2dsb2JhbABagw2BKgSCeMx2ARl6FneEBAEBAwEjEUUQAgEIGgImAgICMBUQAgQBDQWIOgimS5UsAReBLI4hB4J5NoEdAQSRMYsrlR6DYWyBSIEHAQEB X-IronPort-AV: E=Sophos;i="5.04,450,1406592000"; d="scan'208";a="351781100" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-1.cisco.com with ESMTP; 02 Sep 2014 16:31:34 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s82GVXio010284 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 2 Sep 2014 16:31:33 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.68]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0195.001; Tue, 2 Sep 2014 11:31:33 -0500 From: "Joe Hildebrand (jhildebr)" To: Peter Saint-Andre , =?utf-8?B?UGF0cmlrIEbDpGx0c3Ryw7Zt?= , John Klensin Thread-Topic: [precis] review of codepoint table in draft-ietf-precis-framework-17 Thread-Index: AQHPwtCzUXM0y4hYL0C2DuBUsW/wX5vmchEAgAFNUACAAH/CAIAAH4kAgAAJAICAAKFTgIAFIQmA///VLwCAAGVSgP//m9eA Date: Tue, 2 Sep 2014 16:31:32 +0000 Message-ID: References: <96BB5F7A8B584612998969F2@JcK-HP8200.jck.com> <2C363036-165C-4BFF-A505-7097F46D71AF@cisco.com> <018E0736DCDA1E4C8CD084B4@JcK-HP8200.jck.com> <5400E32E.8050309@stpeter.im> <4E4A22237D1D05417D61EC96@JcK-HP8200.jck.com> <29943805-D48F-4DF7-9E4E-5D3D8FBCBB31@frobbit.se> <5405BF83.1050201@stpeter.im> <5405F097.9020600@stpeter.im> In-Reply-To: <5405F097.9020600@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/15.3.0.140730 x-originating-ip: [10.129.24.156] Content-Type: text/plain; charset="utf-8" Content-ID: <63720D896EF4E943AF1CA0C174845CD9@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/precis/APVWgMKhymIcGuAU_VQsbyVL4cQ Cc: "precis@ietf.org" Subject: Re: [precis] review of codepoint table in draft-ietf-precis-framework-17 X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 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 Sep 2014 16:31:34 -0000 T24gOS8yLzE0LCA0OjMwIFBNLCAiUGV0ZXIgU2FpbnQtQW5kcmUiIDxzdHBldGVyQHN0cGV0ZXIu aW0+IHdyb3RlOg0KDQo+PiBJJ20gZmluZSB3aXRoIHRoaXMgYXBwcm9hY2ggYXMgd2VsbC4gIEkg d2FzIGdvaW5nIHRvIHN1Z2dlc3QgbW92aW5nIHRoZQ0KPj4gc3RhcnQgb2YgdGhlIFBSRUNJUyBi bG9jayB0byAiUCIsIGJ1dCBJIGRvbid0IHRoaW5rIGl0J3Mgd29ydGggdGhlIA0KPj5oYXNzbGUu DQo+DQo+WWVhaCBidXQgZG8gd2UgaGF2ZSBhIGkyNiBwcm9ibGVtIHdoZW4gd2UgcnVuIG91dCBv ZiBsZXR0ZXJzIGZyb20gdGhlIA0KPkxhdGluIGFscGhhYmV0PyA7LSkNCg0KSGVoLiAgTm8uICBU aGUgcnVsZSBuYW1lcyBkb24ndCBnbyBpbiBwcm90b2NvbCBzbG90cy4NCg0KLS0gDQpKb2UgSGls ZGVicmFuZA0KDQoNCg0K From nobody Tue Sep 2 17:42:35 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E0B11A8919 for ; Tue, 2 Sep 2014 17:42:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0SJAEpfELS-t for ; Tue, 2 Sep 2014 17:42:33 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E33C1A8916 for ; Tue, 2 Sep 2014 17:42:33 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s830gWY8011495 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 3 Sep 2014 00:42:32 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s830gViI014881 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Sep 2014 00:42:31 GMT Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s830gURm028638; Wed, 3 Sep 2014 00:42:30 GMT Received: from [144.25.110.187] (/144.25.110.187) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 02 Sep 2014 17:42:30 -0700 Message-ID: <540663F4.1040409@oracle.com> Date: Tue, 02 Sep 2014 17:42:28 -0700 From: Dan Chiba Organization: Oracle Corporation User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Peter Saint-Andre References: <53FBCC7B.5090700@oracle.com> <53FBE359.3060102@oracle.com> <53FBE4F5.4060804@stpeter.im> <53FBE847.1080305@oracle.com> <5400FB7C.60104@stpeter.im> In-Reply-To: <5400FB7C.60104@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Archived-At: http://mailarchive.ietf.org/arch/msg/precis/Kb5LLHQPQ5uPTVcOsUi_nqBOu6o Cc: precis@ietf.org Subject: Re: [precis] PRECIS profiles appear underspecified X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 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, 03 Sep 2014 00:42:35 -0000 Thank you Peter for the explanation. Yes, I am looking for a way that allows clients to tell in advance precisely what rules the server will apply with regard to case mapping. Precis operations for the same kind of string can take place in various places in different tiers and their behavior should be consistent. The usernames "fussball" and "fußball" should be treated as equal for case insensitive matching, or as distinct for case sensitive matching. In a worst case, distinct but confusable accounts might be confused. Such problems would never happen if the components designated the complete spec of the username string matching. If the profile doesn't fully specify the spec but it's up to the deployment/service policies, I would like the components to be able to identify the policies precisely. The components that perform precis processing are distributed and they have to be coordinated with respect to the deployment/service policies. With a standard naming scheme for them it would be much easier to coordinate them. Implementers would have to make that up anyway, and it would be hard for application developers to tell the difference between different UsenameIdentifierClass implementations. I am aware the ICU project has implemented SASLprep. It appears the SASL implementation has no ambiguity regarding case mappings; cases are preserved in the example: 2 user user no transformation 3 USER USER case preserved, will not match #2 I expect the same clarity in PRECIS. I do believe case insensitive matching should be enabled. I think a small number of popular recipes for usernames should be identified and standardized as a profile or a deployment/service policy, however it is called. Regards, -Dan On 8/29/2014 3:15 PM, Peter Saint-Andre wrote: > On 8/25/14, 7:52 PM, Dan Chiba wrote: >> Hi Peter, >> >> This is essentially generic but I think the degree of impact would vary, >> depending on the profile. UsenameIdentifierClass would be one of those >> severely affected because it is important to evaluate usernames >> correctly and there are various common practices of handing them. >> Sometimes case insensitive, sometimes sensitive, among others. > > Correct. Which is why it's difficult to formulate one rule for all > treatments of usernames, and why it took quite a bit of discussion to > come to consensus on the text in Section 4.2.1 of the SASLprepbis > specification: > > http://tools.ietf.org/html/draft-ietf-precis-saslprepbis-07#section-4.2.1 > > If I understand your original message correctly, you are looking for a > way that, say, client software can know in advance how a server will > treat usernames with regard to case mapping, based on the SASL > mechanism or application protocol in use. I was looking for that, too. > Unfortunately, our friends in the KITTEN WG (which works on SASL) were > insistent - and correct - that there is no deterministic formula here > because case mapping can even be a matter of deployment or service > policy and thus not determined by the SASL mechanism or application > protocol in use. Thus our carefully-crafted text in Section 4.2.1. > > I wish I could report happier news. > > Peter > > From nobody Tue Sep 2 18:35:23 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87E8D1A8939 for ; Tue, 2 Sep 2014 18:35:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 57NFMCCNX0RX for ; Tue, 2 Sep 2014 18:35:21 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 2F3861A8930 for ; Tue, 2 Sep 2014 18:35:21 -0700 (PDT) Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E273041269; Tue, 2 Sep 2014 19:36:25 -0600 (MDT) Message-ID: <54067058.6060000@stpeter.im> Date: Tue, 02 Sep 2014 19:35:20 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "precis@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/precis/aabw125VA64nloynFVaqAqkNcx8 Subject: [precis] next steps X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 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, 03 Sep 2014 01:35:22 -0000 This evening I plan to submit: draft-ietf-precis-framework-18 draft-saintandre-precis-codepoints-00 It is likely that framework-18 will not address every issue that John Klensin raised in his message of April 24: http://www.ietf.org/mail-archive/web/precis/current/msg00749.html However, in the interest of making progress I think it will be useful to address the larger issues at this time, then submit a revised I-D that addresses the smaller issues. Peter From nobody Tue Sep 2 18:40:22 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D71281A8949; Tue, 2 Sep 2014 18:40:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QR6CUbCSDWOO; Tue, 2 Sep 2014 18:40:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 827361A8953; Tue, 2 Sep 2014 18:40:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140903014014.32210.37992.idtracker@ietfa.amsl.com> Date: Tue, 02 Sep 2014 18:40:14 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/precis/5Bw7WfQRAfxsD7wCRYNrdmiltC8 Cc: precis@ietf.org Subject: [precis] I-D Action: draft-ietf-precis-framework-18.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 01:40:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Preparation and Comparison of Internationalized Strings Working Group of the IETF. Title : PRECIS Framework: Preparation and Comparison of Internationalized Strings in Application Protocols Authors : Peter Saint-Andre Marc Blanchet Filename : draft-ietf-precis-framework-18.txt Pages : 33 Date : 2014-09-02 Abstract: Application protocols using Unicode characters 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 ("PRECIS") in a way that depends on the properties of Unicode characters 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). 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-18 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-precis-framework-18 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Sep 2 18:40:25 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F07611A8949 for ; Tue, 2 Sep 2014 18:40:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X36r08_Eu-03; Tue, 2 Sep 2014 18:40:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D2BE51A894C; Tue, 2 Sep 2014 18:40:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: precis-chairs@tools.ietf.org, draft-ietf-precis-framework@tools.ietf.org, precis@ietf.org, presnick@qti.qualcomm.com X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140903014014.32210.42545.idtracker@ietfa.amsl.com> Date: Tue, 02 Sep 2014 18:40:14 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/precis/1mLf-KyKsR06OSSiWXLBJvynLSA Subject: [precis] New Version Notification - draft-ietf-precis-framework-18.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 01:40:20 -0000 A new version (-18) has been submitted for draft-ietf-precis-framework: http://www.ietf.org/internet-drafts/draft-ietf-precis-framework-18.txt Sub state has been changed to AD Followup from Revised ID Needed The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-precis-framework/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-precis-framework-18 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Tue Sep 2 18:50:52 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 632DE1A8949 for ; Tue, 2 Sep 2014 18:50:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SDNGMiMYaHP1 for ; Tue, 2 Sep 2014 18:50:49 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 847421A8947 for ; Tue, 2 Sep 2014 18:50:49 -0700 (PDT) Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 450A541269; Tue, 2 Sep 2014 19:51:54 -0600 (MDT) Message-ID: <540673EF.6010303@stpeter.im> Date: Tue, 02 Sep 2014 19:50:39 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "precis@ietf.org" References: <20140903014239.29986.26744.idtracker@ietfa.amsl.com> In-Reply-To: <20140903014239.29986.26744.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20140903014239.29986.26744.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/precis/kkAcXXARQ2ypmEdrBGiHPwzLmA0 Subject: [precis] Fwd: New Version Notification for draft-saintandre-precis-codepoints-00.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 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, 03 Sep 2014 01:50:51 -0000 FYI. -------- Original Message -------- Subject: New Version Notification for draft-saintandre-precis-codepoints-00.txt Date: Tue, 02 Sep 2014 18:42:39 -0700 From: internet-drafts@ietf.org To: Peter Saint-Andre , "Peter Saint-Andre" A new version of I-D, draft-saintandre-precis-codepoints-00.txt has been successfully submitted by Peter Saint-Andre and posted to the IETF repository. Name: draft-saintandre-precis-codepoints Revision: 00 Title: PRECIS Codepoint Table Document date: 2014-09-02 Group: Individual Submission Pages: 33 URL: http://www.ietf.org/internet-drafts/draft-saintandre-precis-codepoints-00.txt Status: https://datatracker.ietf.org/doc/draft-saintandre-precis-codepoints/ Htmlized: http://tools.ietf.org/html/draft-saintandre-precis-codepoints-00 Abstract: This document provides a codepoint table, current at the time of publication, that results from applying the rules defined in the PRECIS framework specification to the code points of version 7.0 of the Unicode specification. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Tue Sep 2 23:46:52 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 294A41A86FF for ; Tue, 2 Sep 2014 23:46:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dAB92Byy1PWP for ; Tue, 2 Sep 2014 23:46:50 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FB611A702C for ; Tue, 2 Sep 2014 23:46:49 -0700 (PDT) Received: from mx1.yitter.info (unknown [81.213.27.43]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 4AE738A031 for ; Wed, 3 Sep 2014 06:46:48 +0000 (UTC) Date: Wed, 3 Sep 2014 09:46:47 +0300 From: Andrew Sullivan To: precis@ietf.org Message-ID: <20140903064647.GC40310@mx1.yitter.info> References: <53FBCC7B.5090700@oracle.com> <53FBE359.3060102@oracle.com> <53FBE4F5.4060804@stpeter.im> <53FBE847.1080305@oracle.com> <5400FB7C.60104@stpeter.im> <540663F4.1040409@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <540663F4.1040409@oracle.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/precis/bBZdIk-AS7eepb9TxjpBddysfGA Subject: Re: [precis] PRECIS profiles appear underspecified X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 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, 03 Sep 2014 06:46:51 -0000 On Tue, Sep 02, 2014 at 05:42:28PM -0700, Dan Chiba wrote: > usernames "fussball" and "fußball" should be treated as equal for case > insensitive matching, or as distinct for case sensitive matching. I don't see any case in those two strings. What am I missing? But anyway, it's not clear to me that the usernames "fussball" and "fußball" should in fact always and everywhere be treated as equal. For my understanding is that the use of ß is very much a localization issue: the ligature is never used in Swiss written German. One could argue that it'd be extremely unwise to permit distinct user registrations that are otherwise identical except for ss and ß (certainly I would). But if we think that's a good reason to insist on a mapping, then that would also seem to be a good reason to say, "No case folding, period." Indeed, that's one of the big differences between IDNA2003 and IDNA2008; IDNA2008 violates a deep tradition in the DNS in this way, basically because we couldn't make the mapping work the way we'd like. > username string matching. If the profile doesn't fully specify the spec but > it's up to the deployment/service policies, I would like the components to > be able to identify the policies precisely. While I agree with that in principle, it sounds like an interoperability and implementation nightmare (which issue is, I think, what got us the current compromise text). Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Wed Sep 3 05:35:35 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3708A1A0255 for ; Wed, 3 Sep 2014 05:35:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.268 X-Spam-Level: X-Spam-Status: No, score=-3.268 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NRqvQ9ZE63-h for ; Wed, 3 Sep 2014 05:35:31 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB04C1A00EC for ; Wed, 3 Sep 2014 05:35:31 -0700 (PDT) Received: from [198.252.137.121] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XP9mb-000EAv-H6; Wed, 03 Sep 2014 08:35:29 -0400 Date: Wed, 03 Sep 2014 08:35:24 -0400 From: John C Klensin To: Andrew Sullivan , precis@ietf.org Message-ID: <9B7BBDD3F50EC385A95E8EB9@JcK-HP8200.jck.com> In-Reply-To: <20140903064647.GC40310@mx1.yitter.info> References: <53FBCC7B.5090700@oracle.com> <53FBE359.3060102@oracle.com> <53FBE4F5.4060804@stpeter.im> <53FBE847.1080305@oracle.com> <5400FB7C.60104@stpeter.im> <540663F4.1040409@oracle.com> <20140903064647.GC40310@mx1.yitter.info> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.121 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/precis/UHcWCVXdQD1TvVmrM1iycxmtYC4 Subject: Re: [precis] PRECIS profiles appear underspecified X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 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, 03 Sep 2014 12:35:33 -0000 --On Wednesday, September 03, 2014 09:46 +0300 Andrew Sullivan wrote: > On Tue, Sep 02, 2014 at 05:42:28PM -0700, Dan Chiba wrote: >> usernames "fussball" and "fu=C3=9Fball" should be treated as >> equal for case insensitive matching, or as distinct for case >> sensitive matching.=20 >=20 > I don't see any case in those two strings. What am I missing? That applying ToCaseFold(fu=C3=9Fball) yields "fussball". The reasons why that made sense were clear, although questioned in some quarters, when it was done. Whatever else can be said about it, it (and similar issues such as those with dotless "i") are generally much less problematic in running text and/or when the language and locale context are known than with, e.g., short identifiers with no language context (such as with IDNA and at least some PRECIS contexts). At this stage, stability rules prevent any reconsideration in the Unicode context: if the ToCaseFold behavior is not satisfactory for a given context, that operation either needs to be avoided (as IDNA2008 does) or replaced by something else. > But anyway, it's not clear to me that the usernames "fussball" > and "fu=C3=9Fball" should in fact always and everywhere be = treated > as equal. For my understanding is that the use of =C3=9F is = very > much a localization issue: the ligature is never used in Swiss > written German. One could argue that it'd be extremely unwise > to permit distinct user registrations that are otherwise > identical except for ss and =C3=9F (certainly I would). But = if we > think that's a good reason to insist on a mapping, then that > would also seem to be a good reason to say, "No case folding, > period." Indeed, that's one of the big differences between > IDNA2003 and IDNA2008; IDNA2008 violates a deep tradition in > the DNS in this way, basically because we couldn't make the > mapping work the way we'd like. I would question the "deep tradition" because, in reality, it applies only to the ASCII repertoire, i.e., a subset of the set of undecorated Latin characters. I note that, for scripts that do not have case as that term is understood in Greek-Latin-Cyrillic but that do have Initial-Medial-Final-Isolated distinctions, no one of whom I'm aware has seriously suggested the CharPositionFormFold operation and we have dealt with those cases inconsistently by banning one of the forms, quietly mapping them into another form and losing whatever information might be present (the option IDNA2008 quite deliberately eliminated), or treating them as distinct. >... best, john From nobody Wed Sep 3 05:51:07 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9C471A028A for ; Wed, 3 Sep 2014 05:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.268 X-Spam-Level: X-Spam-Status: No, score=-3.268 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UdMHRrFbE2Fo for ; Wed, 3 Sep 2014 05:51:04 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF5711A00F0 for ; Wed, 3 Sep 2014 05:51:03 -0700 (PDT) Received: from [198.252.137.121] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XPA1a-000EC7-B7; Wed, 03 Sep 2014 08:50:58 -0400 Date: Wed, 03 Sep 2014 08:50:53 -0400 From: John C Klensin To: Peter Saint-Andre , Dan Chiba , precis@ietf.org Message-ID: <8D5595EBB9936678E843A8F2@JcK-HP8200.jck.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.121 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/precis/B67vOe8k7MlXmrU-dUirMUG3XK0 Subject: Re: [precis] PRECIS profiles appear underspecified X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 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, 03 Sep 2014 12:51:05 -0000 --On Friday, August 29, 2014 16:15 -0600 Peter Saint-Andre wrote: > On 8/25/14, 7:52 PM, Dan Chiba wrote: >> Hi Peter, >>=20 >> This is essentially generic but I think the degree of impact >> would vary, depending on the profile. UsenameIdentifierClass >> would be one of those severely affected because it is >> important to evaluate usernames correctly and there are >> various common practices of handing them. Sometimes case >> insensitive, sometimes sensitive, among others. >=20 > Correct. Which is why it's difficult to formulate one rule for > all treatments of usernames, and why it took quite a bit of > discussion to come to consensus on the text in Section 4.2.1 > of the SASLprepbis specification: >=20 > http://tools.ietf.org/html/draft-ietf-precis-saslprepbis-07#se > ction-4.2.1 >=20 > If I understand your original message correctly, you are > looking for a way that, say, client software can know in > advance how a server will treat usernames with regard to case > mapping, based on the SASL mechanism or application protocol > in use. I was looking for that, too. Unfortunately, our > friends in the KITTEN WG (which works on SASL) were insistent > - and correct - that there is no deterministic formula here > because case mapping can even be a matter of deployment or > service policy and thus not determined by the SASL mechanism > or application protocol in use. Thus our carefully-crafted > text in Section 4.2.1. >=20 > I wish I could report happier news. Dan, Let me add an additional perspective to this because it relates to something I've been saying in other contexts and you have, I assume inadvertently, provided another example. This comment is complementary to my response to Andrew on the specific "fu=C3=9Fball" example, which has been used many times with more = or less the same conclusion. While it would be good for user agents to be able to better predict server behavior and that carries with it the problems Peter describes, ultimately computer systems don't care. The users do. For most users, it would be very desirable if all of these systems did what they want and expect -- in this case, case folding should behave with all of the relevant locale and language special cases (Turkic dotless "i" is the most usually cited case, but there are many others, including different conventions about decorated Latin characters in different places). =20 Unfortunately, our experience with DWIM (or "expect" or "want") systems at the individual user language and character-handling level has been pretty poor. For starters, every user interface has to have a method of telling the server, at very fine granularity than we normally use, exactly what its expectations are and servers have to be prepared to deal with that. That, as Andrew points out in a different context, is an implementer's nightmare. I think our efforts might be better spent educating users (by clear error messages if needed) into a different set of expectations than "the computer should be able to figure out what I intended". In the particular case of PRECIS (and IDNA), three things would be extremely helpful: (1) Instead of lots of profiles, sub-profiles, and variations on profiles, reduce the number to an absolute minimum whose applicability can be predicted and, ideally, have those differ only in edge cases. (2) Educate the users that, if they want consistent, predictable, and easy-to-understand behavior, they should simply avoid the edge cases to the extent possible. If we have to consider "upper case" as an edge case in that regard, so be it. (3) Adopt a model that, if two characters are assigned different (after NFC) Unicode code points, they are different, that we simply don't try to figure out the user's intent, and that forms that are more likely to cause confusion than to provide useful distinctions are simply not used together in the same context rather than somehow mapped together. =20 It isn't ideal, but it is at least something we can fully understand even if (3) will still require some judgment for some subset of characters, "=C3=9F", dotless i, and those Final (and other) forms included. best, john From nobody Wed Sep 3 06:08:47 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 271F81A8A62 for ; Wed, 3 Sep 2014 06:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.259 X-Spam-Level: * X-Spam-Status: No, score=1.259 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MeOJZincyNeG for ; Wed, 3 Sep 2014 06:08:26 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5A5D1A8A61 for ; Wed, 3 Sep 2014 06:08:25 -0700 (PDT) Received: from mx1.yitter.info (unknown [81.213.21.172]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 398158A031 for ; Wed, 3 Sep 2014 13:08:24 +0000 (UTC) Date: Wed, 3 Sep 2014 16:08:21 +0300 From: Andrew Sullivan To: precis@ietf.org Message-ID: <20140903130820.GB58910@mx1.yitter.info> References: <53FBCC7B.5090700@oracle.com> <53FBE359.3060102@oracle.com> <53FBE4F5.4060804@stpeter.im> <53FBE847.1080305@oracle.com> <5400FB7C.60104@stpeter.im> <540663F4.1040409@oracle.com> <20140903064647.GC40310@mx1.yitter.info> <9B7BBDD3F50EC385A95E8EB9@JcK-HP8200.jck.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <9B7BBDD3F50EC385A95E8EB9@JcK-HP8200.jck.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/precis/JVtDhJD0ImhvBOVqiX9FDVa3WUM Subject: Re: [precis] PRECIS profiles appear underspecified X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 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, 03 Sep 2014 13:08:27 -0000 On Wed, Sep 03, 2014 at 08:35:24AM -0400, John C Klensin wrote: > > > > I don't see any case in those two strings. What am I missing? > > That applying ToCaseFold(fußball) yields "fussball". Yes, I know. But this is sort of my point. If the matching behaviour of those two strings differ because of _case_ treatment, it's a recipe for user puzzlement at best: "Oh, that's because of case folding." "Um, it's all lower case?" > I would question the "deep tradition" because, in reality, it > applies only to the ASCII repertoire, i.e., a subset of the set > of undecorated Latin characters. Yes, but surely for someone German it's handy to be able to use CamelCase to make strings somewhat more memorable, and having it work when the string has no decorartions and not work when there are decorations is, at least, hard to understand. The only responsible advice in light of IDNA2008, in my opinion, is, "Use domain names are in lower case, always." Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Wed Sep 3 10:09:06 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10DE51A0359 for ; Wed, 3 Sep 2014 10:08:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6gUWgGbSYM_Q for ; Wed, 3 Sep 2014 10:08:42 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29FCE1A03A2 for ; Wed, 3 Sep 2014 10:08:00 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s83H7rQx027688 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 3 Sep 2014 17:07:53 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s83H7qmY025857 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 3 Sep 2014 17:07:53 GMT Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s83H7qXO025847 for ; Wed, 3 Sep 2014 17:07:52 GMT Received: from [144.25.110.187] (/144.25.110.187) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 03 Sep 2014 10:07:52 -0700 Message-ID: <54074AE8.5090806@oracle.com> Date: Wed, 03 Sep 2014 10:07:52 -0700 From: Dan Chiba Organization: Oracle Corporation User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: precis@ietf.org References: <53FBCC7B.5090700@oracle.com> <53FBE359.3060102@oracle.com> <53FBE4F5.4060804@stpeter.im> <53FBE847.1080305@oracle.com> <5400FB7C.60104@stpeter.im> <540663F4.1040409@oracle.com> <20140903064647.GC40310@mx1.yitter.info> In-Reply-To: <20140903064647.GC40310@mx1.yitter.info> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: http://mailarchive.ietf.org/arch/msg/precis/tFMoGLHrHqnGxxIR2zth2swF2Bo Subject: Re: [precis] PRECIS profiles appear underspecified X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 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, 03 Sep 2014 17:08:57 -0000 Hi Andrew, On 9/2/2014 11:46 PM, Andrew Sullivan wrote: > On Tue, Sep 02, 2014 at 05:42:28PM -0700, Dan Chiba wrote: >> usernames "fussball" and "fußball" should be treated as equal for case >> insensitive matching, or as distinct for case sensitive matching. > I don't see any case in those two strings. What am I missing? My bad, both of them are lowercase. My intent was to present two distinct strings that are evaluated as equal in case insensitive matching. "fussball" and "Fussball" would be good examples. > But anyway, it's not clear to me that the usernames "fussball" and > "fußball" should in fact always and everywhere be treated as equal. In my understanding that is not always the case. > For my understanding is that the use of ß is very much a localization > issue: the ligature is never used in Swiss written German. One could > argue that it'd be extremely unwise to permit distinct user > registrations that are otherwise identical except for ss and ß > (certainly I would). But if we think that's a good reason to insist > on a mapping, then that would also seem to be a good reason to say, > "No case folding, period." Indeed, that's one of the big differences > between IDNA2003 and IDNA2008; IDNA2008 violates a deep tradition in > the DNS in this way, basically because we couldn't make the mapping > work the way we'd like. I used the ß character as a case in which distinct strings are to be evaluated equal after precis preparation. I think it is a good idea to disallow confusable characters like this. I do not know the background of IDNA well, but I think there could be a precis profile for it. >> username string matching. If the profile doesn't fully specify the spec but >> it's up to the deployment/service policies, I would like the components to >> be able to identify the policies precisely. > While I agree with that in principle, it sounds like an > interoperability and implementation nightmare (which issue is, I > think, what got us the current compromise text). I am concerned about interoperability problems that may happen due to the ambiguity in the profile spec. Right now, an implementation of UsernameIdentifierClass may use arbitrary character mappings. I agree the compromise was required, but I think it has introduced the problems while partially resolving the other requirement to match the various current practices of mapping some characters in username handling. Best regards, Dan > > Best regards, > > A > From nobody Wed Sep 3 12:42:29 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 730C51A6EDC for ; Wed, 3 Sep 2014 12:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.868 X-Spam-Level: X-Spam-Status: No, score=-1.868 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ITegC7ozhIpZ for ; Wed, 3 Sep 2014 12:42:24 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D1BE1A6F4C for ; Wed, 3 Sep 2014 12:42:24 -0700 (PDT) Received: from [198.252.137.121] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XPGRh-000F33-2F; Wed, 03 Sep 2014 15:42:21 -0400 Date: Wed, 03 Sep 2014 15:42:16 -0400 From: John C Klensin To: Andrew Sullivan , precis@ietf.org Message-ID: <1C3D0023E4FDD113633E5973@JcK-HP8200.jck.com> In-Reply-To: <20140903130820.GB58910@mx1.yitter.info> References: <53FBCC7B.5090700@oracle.com> <53FBE359.3060102@oracle.com> <53FBE4F5.4060804@stpeter.im> <53FBE847.1080305@oracle.com> <5400FB7C.60104@stpeter.im> <540663F4.1040409@oracle.com> <20140903064647.GC40310@mx1.yitter.info> <9B7BBDD3F50EC385A95E8EB9@JcK-HP8200.jck.com> <20140903130820.GB58910@mx1.yitter.info> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.121 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/precis/7IxJfl2sptrS9So08eICT4DMFrU Subject: Re: [precis] PRECIS profiles appear underspecified X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 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, 03 Sep 2014 19:42:26 -0000 --On Wednesday, September 03, 2014 16:08 +0300 Andrew Sullivan wrote: > On Wed, Sep 03, 2014 at 08:35:24AM -0400, John C Klensin = wrote: >> >=20 >> > I don't see any case in those two strings. What am I >> > missing? >>=20 >> That applying ToCaseFold(fu=C3=9Fball) yields "fussball". >=20 > Yes, I know. But this is sort of my point. If the matching > behaviour of those two strings differ because of _case_ > treatment, it's a recipe for user puzzlement at best: >=20 > "Oh, that's because of case folding." >=20 > "Um, it's all lower case?" Indeed. We are in complete agreement... I was just trying to explain how we got here. And part of that is that our practice has been to apply not "toLowerCase" to strings (which many people think they understand even though it can be a little ambiguous in common practice) rather than the case folding operation which few people not familiar with Unicode understand. >> I would question the "deep tradition" because, in reality, it >> applies only to the ASCII repertoire, i.e., a subset of the >> set of undecorated Latin characters. >=20 > Yes, but surely for someone German it's handy to be able to = use > CamelCase to make strings somewhat more memorable, and having > it work when the string has no decorartions and not work when > there are decorations is, at least, hard to understand.=20 Sure. But that is, IMO, for two reasons. First, we "trained" them to expect those variations to match by requiring it for ASCII, thereby setting a very bad precedent for the i18n cases. Second, and more important, it is unclear to me why the users of slightly-decorated Latin text (German included) should expect case matching to work while we tell (in no particular order)=20 (i) Those same Germans that strings containing "=C3=B6" and = those containing "oe" don't match. (ii) Our Greek, Hebrew, and Arabic script-using colleagues that, if Unicode supplies different code points for final (or other) forms than whatever is considered the base, then strings containing the final form are not equal to otherwise-identical ones that don't. (iii) Our ASCII-using colleagues that, while they can write MyFavoriteMovie.example and treat it as equivalent to "myfavoritemovie.example", their preferred form will usually be preserved by the DNS but sometimes won't. (iv) Our English-speaking colleagues that "color" and "colour" are different, even though most of their everyday experience says otherwise. (v) Lots of groups that joespizza.example and joe=CA=BCspizza.example (that is not a single quote/apostrophe) = are not equivalent to each other, that JoesPizza.example is equivalent to the first but Joe=CA=BCsPizza.example is invalid, = and that pizzeriajoe and pizzeragiovanni are not equivalent to any of them or each other. FWIW, I would not be at all surprised if some clever search engine did consider all of the above to be plausible alternatives to each other. (vi, ff) The > only responsible advice in light of IDNA2008, in my opinion, > is, "Use domain names are in lower case, always." And that advice is part of what I meant in an earlier note when I suggested that users avoid edge case and cases in which they expected the computer system to figure out what they meant and do it. Users who don't want surprises and name registrants or creators who don't either will stick to lower case and strings as uncomplicated as possible, and will expect strings to match only if what is in the database and what they type are identical. Since month ago, I would have written "modulo normalization", but the recent discussions about U+08A1 and related code points make even that suspect. john From nobody Wed Sep 3 13:09:11 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAAE01A0658 for ; Wed, 3 Sep 2014 13:09:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.268 X-Spam-Level: X-Spam-Status: No, score=-3.268 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fAOLKB-KKBzC for ; Wed, 3 Sep 2014 13:09:08 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 216F91A6EFC for ; Wed, 3 Sep 2014 13:09:08 -0700 (PDT) Received: from [198.252.137.121] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XPGrY-000F57-Gi; Wed, 03 Sep 2014 16:09:04 -0400 Date: Wed, 03 Sep 2014 16:08:59 -0400 From: John C Klensin To: Peter Saint-Andre , precis@ietf.org Message-ID: In-Reply-To: <54067058.6060000@stpeter.im> References: <54067058.6060000@stpeter.im> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.121 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/precis/RF-pnxbiTiw48cvJHzqi-hQBDzg Subject: [precis] Codepoints (mostly) (was: Re: next steps) X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 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, 03 Sep 2014 20:09:09 -0000 --On Tuesday, September 02, 2014 19:35 -0600 Peter Saint-Andre wrote: > This evening I plan to submit: > > draft-ietf-precis-framework-18 > draft-saintandre-precis-codepoints-00 > > It is likely that framework-18 will not address every issue > that John Klensin raised in his message of April 24: > > http://www.ietf.org/mail-archive/web/precis/current/msg00749.h > tml > > However, in the interest of making progress I think it will be > useful to address the larger issues at this time, then submit > a revised I-D that addresses the smaller issues. Seems sensible to me. I'll try to start working through the new version of framework RSN. Questions/comments about "codepoints" and your intent: First, I think having the tables separate and unambiguously illustrative and Informational, is a desirable step. Second, because I'm still concerned about U+08A1 (for those who don't know why, see discussion on IDNA list and elsewhere), I looked it up and found "". That is consistent with my preference at the moment but: Your explanation in Section 1 says that this is based strictly on Unicode 7.0. If calculated according to the existing rules and Unicode 7.0, it is clearly assigned. I think it is valid and has a category, probably PVALID, there is nothing "UNASSIGNED" about it. Editorial recommendation: Recognizing the line length limits, I think it would be desirable to at least try to spell out the script names or, if that is not impossible, to provide a script name <-> abbreviation table. It will make things much easier to find it people go looking for the characters in a script that are usable. I assume that would be a common case. john From nobody Tue Sep 9 18:18:43 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 448BD1A03F6 for ; Tue, 9 Sep 2014 18:18:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.854 X-Spam-Level: X-Spam-Status: No, score=-0.854 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-1.652, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SmiVo7k1oysT for ; Tue, 9 Sep 2014 18:18:39 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 38E5C1A03F3 for ; Tue, 9 Sep 2014 18:18:39 -0700 (PDT) Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 61CA241300; Tue, 9 Sep 2014 19:20:14 -0600 (MDT) Message-ID: <540FA6EE.4050904@stpeter.im> Date: Tue, 09 Sep 2014 19:18:38 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Dan Chiba , precis@ietf.org References: <53FBCC7B.5090700@oracle.com> <53FBE359.3060102@oracle.com> <53FBE4F5.4060804@stpeter.im> <53FBE847.1080305@oracle.com> <5400FB7C.60104@stpeter.im> <540663F4.1040409@oracle.com> <20140903064647.GC40310@mx1.yitter.info> <54074AE8.5090806@oracle.com> In-Reply-To: <54074AE8.5090806@oracle.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/precis/aJ9iGwUslWQ4zONMtknLTcrAJ2E Subject: Re: [precis] PRECIS profiles appear underspecified X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 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 Sep 2014 01:18:41 -0000 On 9/3/14, 11:07 AM, Dan Chiba wrote: > Hi Andrew, > > On 9/2/2014 11:46 PM, Andrew Sullivan wrote: >> On Tue, Sep 02, 2014 at 05:42:28PM -0700, Dan Chiba wrote: >>> usernames "fussball" and "fußball" should be treated as equal for case >>> insensitive matching, or as distinct for case sensitive matching. >> I don't see any case in those two strings. What am I missing? > My bad, both of them are lowercase. My intent was to present two > distinct strings that are evaluated as equal in case insensitive > matching. "fussball" and "Fussball" would be good examples. >> But anyway, it's not clear to me that the usernames "fussball" and >> "fußball" should in fact always and everywhere be treated as equal. > In my understanding that is not always the case. >> For my understanding is that the use of ß is very much a localization >> issue: the ligature is never used in Swiss written German. One could >> argue that it'd be extremely unwise to permit distinct user >> registrations that are otherwise identical except for ss and ß >> (certainly I would). But if we think that's a good reason to insist >> on a mapping, then that would also seem to be a good reason to say, >> "No case folding, period." Indeed, that's one of the big differences >> between IDNA2003 and IDNA2008; IDNA2008 violates a deep tradition in >> the DNS in this way, basically because we couldn't make the mapping >> work the way we'd like. > I used the ß character as a case in which distinct strings are to be > evaluated equal after precis preparation. I think it is a good idea to > disallow confusable characters like this. I do not know the background > of IDNA well, but I think there could be a precis profile for it. Disallowing confusable characters is a laudable goal, but very difficult in practice. Section 9.5 of the precis-framework document covers these issues in some detail. Here's one of my favorite examples: https://stpeter.im/journal/1420.html >>> username string matching. If the profile doesn't fully specify the >>> spec but >>> it's up to the deployment/service policies, I would like the >>> components to >>> be able to identify the policies precisely. >> While I agree with that in principle, it sounds like an >> interoperability and implementation nightmare (which issue is, I >> think, what got us the current compromise text). > I am concerned about interoperability problems that may happen due to > the ambiguity in the profile spec. Right now, an implementation of > UsernameIdentifierClass may use arbitrary character mappings. I agree > the compromise was required, but I think it has introduced the problems > while partially resolving the other requirement to match the various > current practices of mapping some characters in username handling. As far as I can see, the only alternative to the compromise we've brokered here is (my understanding of) what John suggests: lock down the base string classes, effectively disallow profiles, and tell existing applications to conform to the new rules. If they want exceptions, then they don't have to use PRECIS. In my opinion, that would be slightly at odds with the spirit of how the PRECIS WG was formed, since all of the Stringprep "customers" in the room at the NewPrep BoF had existing profiles and wanted to figure out how to use modern versions of Unicode while supporting as many of their existing strings/identifiers as possible. If we now tell those customers that we can't meet their needs, I don't think they will be particularly happy. But, as John also says, this is about pleasing (or at least minimizing confusion for) end users. Peter From nobody Tue Sep 9 18:29:26 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E55E01A0462 for ; Tue, 9 Sep 2014 18:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.554 X-Spam-Level: X-Spam-Status: No, score=-3.554 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eMY_V-dxB3KV for ; Tue, 9 Sep 2014 18:29:23 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 47AC31A03F2 for ; Tue, 9 Sep 2014 18:29:23 -0700 (PDT) Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B75EA41300; Tue, 9 Sep 2014 19:30:58 -0600 (MDT) Message-ID: <540FA972.5050004@stpeter.im> Date: Tue, 09 Sep 2014 19:29:22 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: John C Klensin , precis@ietf.org References: <54067058.6060000@stpeter.im> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/precis/l9QtXrRq-l0S3qVkRd8_g7vEIGQ Subject: Re: [precis] Codepoints (mostly) X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 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 Sep 2014 01:29:25 -0000 On 9/3/14, 2:08 PM, John C Klensin wrote: > > > --On Tuesday, September 02, 2014 19:35 -0600 Peter Saint-Andre > wrote: > >> This evening I plan to submit: >> >> draft-ietf-precis-framework-18 >> draft-saintandre-precis-codepoints-00 >> >> It is likely that framework-18 will not address every issue >> that John Klensin raised in his message of April 24: >> >> http://www.ietf.org/mail-archive/web/precis/current/msg00749.h >> tml >> >> However, in the interest of making progress I think it will be >> useful to address the larger issues at this time, then submit >> a revised I-D that addresses the smaller issues. > > Seems sensible to me. I'll try to start working through the new > version of framework RSN. > > Questions/comments about "codepoints" and your intent: > > First, I think having the tables separate and unambiguously > illustrative and Informational, is a desirable step. Second, > because I'm still concerned about U+08A1 (for those who don't > know why, see discussion on IDNA list and elsewhere), I looked > it up and found "". That is consistent with my > preference at the moment but: > > Your explanation in Section 1 says that this is based strictly > on Unicode 7.0. Actually I just copied over the table from the framework draft and we last ran our respective code against Unicode 6.3, so we'll need to recalculate the table. I was a bit too quick about updating the explanatory text. My apologies. > If calculated according to the existing rules > and Unicode 7.0, it is clearly assigned. I think it is valid > and has a category, probably PVALID, there is nothing > "UNASSIGNED" about it. And there are other changes, since Unicode 7.0 added 2,834 new characters according to http://unicode.org/versions/Unicode7.0.0/ > Editorial recommendation: Recognizing the line length limits, I > think it would be desirable to at least try to spell out the > script names or, if that is not impossible, to provide a script > name <-> abbreviation table. It will make things much easier to > find it people go looking for the characters in a script that > are usable. I assume that would be a common case. Thanks for the helpful suggestion. Peter From nobody Wed Sep 10 11:09:45 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C4FE1A7D84 for ; Wed, 10 Sep 2014 11:09:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.252 X-Spam-Level: X-Spam-Status: No, score=-4.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hUzy0rMVg5sG for ; Wed, 10 Sep 2014 11:09:33 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 915951A82E2 for ; Wed, 10 Sep 2014 11:09:31 -0700 (PDT) Received: from h8.int.jck.com ([198.252.137.35] helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XRmKU-000HQX-2r; Wed, 10 Sep 2014 14:09:18 -0400 Date: Wed, 10 Sep 2014 14:09:12 -0400 From: John C Klensin To: Peter Saint-Andre Message-ID: <547C8DE7CF2396F5F0AD3EBA@JcK-HP8200.jck.com> In-Reply-To: <540FA6EE.4050904@stpeter.im> References: <53FBCC7B.5090700@oracle.com> <53FBE359.3060102@oracle.com> <53FBE4F5.4060804@stpeter.im> <53FBE847.1080305@oracle.com> <5400FB7C.60104@stpeter.im> <540663F4.1040409@oracle.com> <20140903064647.GC40310@mx1.yitter.info> <54074AE8.5090806@oracle.com> <540FA6EE.4050904@stpeter.im> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/precis/M7yv-KWbjqTvqUndU2bK3OFCJTc Cc: precis@ietf.org Subject: Re: [precis] PRECIS profiles appear underspecified X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 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 Sep 2014 18:09:39 -0000 --On Tuesday, September 09, 2014 19:18 -0600 Peter Saint-Andre wrote: >... > As far as I can see, the only alternative to the compromise > we've brokered here is (my understanding of) what John > suggests: lock down the base string classes, effectively > disallow profiles, and tell existing applications to conform > to the new rules. If they want exceptions, then they don't > have to use PRECIS. I've suggested several slightly different things in the hope of finding a solution that would be acceptable to everyone (or at least "many"). I don't think the above is one of them, but it is possible. I am really no more interested than anyone else sensible in invalidating applications that work now. My goals are to keep the user experience predictable and to minimize maintenance responsibilities and costs. What I have suggested would be a slight variation on the above, replacing "tell existing applications to conform" and "don't have to use" with an explicit section of the PRECIS standard that would say, more or less, "While it is recommended for predictability that applications conform narrowly to the base strings classes and rules, applications may need to make exceptions to allow or disallow particular characters for historical or other reasons. Such applications are still conformant to PRECIS if they their protocol specifications precisely identify the characters affected." I assume that we would than either add a per-application list of exceptions or put in language passing on that responsibility to the applications. I also assume that any applications that intended to expand their lists in the future (i.e., not simply have exceptions as a legacy matter) would create IANA registries for their exceptions lists (not complete tables) and that text about exception for those applications would point to the registries. > In my opinion, that would be slightly at odds with the spirit > of how the PRECIS WG was formed, since all of the Stringprep > "customers" in the room at the NewPrep BoF had existing > profiles and wanted to figure out how to use modern versions > of Unicode while supporting as many of their existing > strings/identifiers as possible. If we now tell those > customers that we can't meet their needs, I don't think they > will be particularly happy. I agree with that goal and have all along. But, again, I'd like to move as much as possible toward a minimum number of definitions/ tables/ profiles with exception lists as needed. The latter are not ideal -- there is no way to get to ideal while preserving backward compatibility -- but, if they are treated as necessary exceptions and about edge cases (which they mostly are), then I think we will be ok. > But, as John also says, this is > about pleasing (or at least minimizing confusion for) end > users. FWIW, I do see the goal of minimizing user confusion to be diametrically opposite to the notion that we should have many profiles and the potential for variations on each that I believe Dan has suggested. Either that or I still don't understand his suggestion/ request. john From nobody Wed Sep 10 19:11:35 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80BB01A0359 for ; Wed, 10 Sep 2014 19:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.554 X-Spam-Level: X-Spam-Status: No, score=-3.554 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iLKVGflPuO_2 for ; Wed, 10 Sep 2014 19:11:32 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 04FE11A0345 for ; Wed, 10 Sep 2014 19:11:32 -0700 (PDT) Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 16C6641360; Wed, 10 Sep 2014 20:13:11 -0600 (MDT) Message-ID: <541104D3.6090208@stpeter.im> Date: Wed, 10 Sep 2014 20:11:31 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "precis@ietf.org" References: <54110188.7070202@stpeter.im> In-Reply-To: <54110188.7070202@stpeter.im> X-Forwarded-Message-Id: <54110188.7070202@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/precis/gb9uCKRQa-5e740NBbGyAH9jTs8 Subject: [precis] Fwd: Re: [xmpp] I-D Action: draft-ietf-xmpp-6122bis-13.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 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 Sep 2014 02:11:33 -0000 FYI. Some of what I've proposed in this document might apply to other specs, too (e.g., how we organized saslprepbis and nickname). Peter -------- Original Message -------- Subject: Re: [xmpp] I-D Action: draft-ietf-xmpp-6122bis-13.txt Date: Wed, 10 Sep 2014 19:57:28 -0600 From: Peter Saint-Andre To: xmpp@ietf.org Changes to address feedback from Joe and Florian. Please review carefully, because some of the changes are subtle or provisional - more feedback would be very helpful. Thanks! Peter On 9/10/14, 7:52 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 Extensible Messaging and Presence Protocol Working Group of the IETF. > > Title : Extensible Messaging and Presence Protocol (XMPP): Address Format > Author : Peter Saint-Andre > Filename : draft-ietf-xmpp-6122bis-13.txt > Pages : 29 > Date : 2014-09-10 > > Abstract: > This document defines the address format for the Extensible Messaging > and Presence Protocol (XMPP), including support for code points > outside the ASCII range. This document obsoletes RFC 6122. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-xmpp-6122bis/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-xmpp-6122bis-13 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-xmpp-6122bis-13 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > xmpp mailing list > xmpp@ietf.org > https://www.ietf.org/mailman/listinfo/xmpp > _______________________________________________ xmpp mailing list xmpp@ietf.org https://www.ietf.org/mailman/listinfo/xmpp From nobody Thu Sep 18 13:05:33 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 800B71A88E7 for ; Thu, 18 Sep 2014 13:05:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.153 X-Spam-Level: X-Spam-Status: No, score=-5.153 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0d00nicovLZw for ; Thu, 18 Sep 2014 13:05:29 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C33F1A88E1 for ; Thu, 18 Sep 2014 13:05:29 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s8IK5RvG013925 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 18 Sep 2014 20:05:28 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s8IK5OGR009719 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Sep 2014 20:05:26 GMT Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s8IK5O9O011906; Thu, 18 Sep 2014 20:05:24 GMT Received: from [144.25.110.187] (/144.25.110.187) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 18 Sep 2014 13:05:23 -0700 Message-ID: <541B3AFD.9040304@oracle.com> Date: Thu, 18 Sep 2014 13:05:17 -0700 From: Dan Chiba Organization: Oracle Corporation User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: John C Klensin References: <8D5595EBB9936678E843A8F2@JcK-HP8200.jck.com> In-Reply-To: <8D5595EBB9936678E843A8F2@JcK-HP8200.jck.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Archived-At: http://mailarchive.ietf.org/arch/msg/precis/A6yCxBIGziwocEaOYOrUazTH_5I Cc: precis@ietf.org Subject: Re: [precis] PRECIS profiles appear underspecified X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 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, 18 Sep 2014 20:05:32 -0000 Thank you John for educating me with the background and the ideas to mitigate the pain. My comments to specific points are inline: On 9/3/2014 5:50 AM, John C Klensin wrote: > > --On Friday, August 29, 2014 16:15 -0600 Peter Saint-Andre > wrote: > >> On 8/25/14, 7:52 PM, Dan Chiba wrote: >>> Hi Peter, >>> >>> This is essentially generic but I think the degree of impact >>> would vary, depending on the profile. UsenameIdentifierClass >>> would be one of those severely affected because it is >>> important to evaluate usernames correctly and there are >>> various common practices of handing them. Sometimes case >>> insensitive, sometimes sensitive, among others. >> Correct. Which is why it's difficult to formulate one rule for >> all treatments of usernames, and why it took quite a bit of >> discussion to come to consensus on the text in Section 4.2.1 >> of the SASLprepbis specification: >> >> http://tools.ietf.org/html/draft-ietf-precis-saslprepbis-07#se >> ction-4.2.1 >> >> If I understand your original message correctly, you are >> looking for a way that, say, client software can know in >> advance how a server will treat usernames with regard to case >> mapping, based on the SASL mechanism or application protocol >> in use. I was looking for that, too. Unfortunately, our >> friends in the KITTEN WG (which works on SASL) were insistent >> - and correct - that there is no deterministic formula here >> because case mapping can even be a matter of deployment or >> service policy and thus not determined by the SASL mechanism >> or application protocol in use. Thus our carefully-crafted >> text in Section 4.2.1. >> >> I wish I could report happier news. > Dan, > > Let me add an additional perspective to this because it relates > to something I've been saying in other contexts and you have, I > assume inadvertently, provided another example. This comment is > complementary to my response to Andrew on the specific > "fußball" example, which has been used many times with more or > less the same conclusion. > > While it would be good for user agents to be able to better > predict server behavior and that carries with it the problems > Peter describes, ultimately computer systems don't care. The > users do. For most users, it would be very desirable if all of > these systems did what they want and expect -- in this case, > case folding should behave with all of the relevant locale and > language special cases (Turkic dotless "i" is the most usually > cited case, but there are many others, including different > conventions about decorated Latin characters in different > places). > > Unfortunately, our experience with DWIM (or "expect" or "want") > systems at the individual user language and character-handling > level has been pretty poor. For starters, every user interface > has to have a method of telling the server, at very fine > granularity than we normally use, exactly what its expectations > are and servers have to be prepared to deal with that. That, as > Andrew points out in a different context, is an implementer's > nightmare. > > I think our efforts might be better spent educating users (by > clear error messages if needed) into a different set of > expectations than "the computer should be able to figure out > what I intended". In the particular case of PRECIS (and > IDNA), three things would be extremely helpful: > > (1) Instead of lots of profiles, sub-profiles, and variations on > profiles, reduce the number to an absolute minimum whose > applicability can be predicted and, ideally, have those differ > only in edge cases. I totally agree with this. It's ideal for the UsernameIdentifierClass profile to be used predominantly with as little variations as possible. Having a lot of variations defeats the purpose. > (2) Educate the users that, if they want consistent, > predictable, and easy-to-understand behavior, they should simply > avoid the edge cases to the extent possible. If we have to > consider "upper case" as an edge case in that regard, so be it. Yes. It is not clear to me what compatibility issues the users may face, but I think it's important to get as many users to stick to the default profile as possible. > (3) Adopt a model that, if two characters are assigned different > (after NFC) Unicode code points, they are different, that we > simply don't try to figure out the user's intent, and that forms > that are more likely to cause confusion than to provide useful > distinctions are simply not used together in the same context > rather than somehow mapped together. It is my understanding that Unicode defines distinct but confusable characters and they should be avoided when they are confusable. > > It isn't ideal, but it is at least something we can fully > understand even if (3) will still require some judgment for some > subset of characters, "ß", dotless i, and those Final (and > other) forms included. "ss" and "ß" are to be considered equivalent with case folding; I don't understand what kind of judgment you think is needed. The regular i and dotless i seem slightly different from ss and ß for being distinct letters, but I think it is possible to treat them as equivalent, as far as precis username comparison is concerned. Turkish users can still use either letter as needed; when prepared, they can be normalized to the same letter. Regards, -Dan > best, > john > > > From nobody Thu Sep 18 13:05:44 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AC8A1A88FB for ; Thu, 18 Sep 2014 13:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.853 X-Spam-Level: X-Spam-Status: No, score=-5.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zz2b5EJ7dssz for ; Thu, 18 Sep 2014 13:05:37 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A93C1A88DC for ; Thu, 18 Sep 2014 13:05:37 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s8IK5Z6q027720 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 18 Sep 2014 20:05:36 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s8IK5XfT020916 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Sep 2014 20:05:34 GMT Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s8IK5XLT012238; Thu, 18 Sep 2014 20:05:33 GMT Received: from [144.25.110.187] (/144.25.110.187) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 18 Sep 2014 13:05:33 -0700 Message-ID: <541B3B0C.2040307@oracle.com> Date: Thu, 18 Sep 2014 13:05:32 -0700 From: Dan Chiba Organization: Oracle Corporation User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Peter Saint-Andre References: <53FBCC7B.5090700@oracle.com> <53FBE359.3060102@oracle.com> <53FBE4F5.4060804@stpeter.im> <53FBE847.1080305@oracle.com> <5400FB7C.60104@stpeter.im> <540663F4.1040409@oracle.com> <20140903064647.GC40310@mx1.yitter.info> <54074AE8.5090806@oracle.com> <540FA6EE.4050904@stpeter.im> In-Reply-To: <540FA6EE.4050904@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Source-IP: acsinet22.oracle.com [141.146.126.238] Archived-At: http://mailarchive.ietf.org/arch/msg/precis/GSkU5XS5oFrMStszUQGA4BGYJ_k Cc: precis@ietf.org Subject: Re: [precis] PRECIS profiles appear underspecified X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 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, 18 Sep 2014 20:05:41 -0000 On 9/9/2014 6:18 PM, Peter Saint-Andre wrote: > On 9/3/14, 11:07 AM, Dan Chiba wrote: >> Hi Andrew, >> >> On 9/2/2014 11:46 PM, Andrew Sullivan wrote: >>> On Tue, Sep 02, 2014 at 05:42:28PM -0700, Dan Chiba wrote: >>>> usernames "fussball" and "fußball" should be treated as equal for case >>>> insensitive matching, or as distinct for case sensitive matching. >>> I don't see any case in those two strings. What am I missing? >> My bad, both of them are lowercase. My intent was to present two >> distinct strings that are evaluated as equal in case insensitive >> matching. "fussball" and "Fussball" would be good examples. >>> But anyway, it's not clear to me that the usernames "fussball" and >>> "fußball" should in fact always and everywhere be treated as equal. >> In my understanding that is not always the case. >>> For my understanding is that the use of ß is very much a localization >>> issue: the ligature is never used in Swiss written German. One could >>> argue that it'd be extremely unwise to permit distinct user >>> registrations that are otherwise identical except for ss and ß >>> (certainly I would). But if we think that's a good reason to insist >>> on a mapping, then that would also seem to be a good reason to say, >>> "No case folding, period." Indeed, that's one of the big differences >>> between IDNA2003 and IDNA2008; IDNA2008 violates a deep tradition in >>> the DNS in this way, basically because we couldn't make the mapping >>> work the way we'd like. >> I used the ß character as a case in which distinct strings are to be >> evaluated equal after precis preparation. I think it is a good idea to >> disallow confusable characters like this. I do not know the background >> of IDNA well, but I think there could be a precis profile for it. > > Disallowing confusable characters is a laudable goal, but very > difficult in practice. Section 9.5 of the precis-framework document > covers these issues in some detail. Here's one of my favorite examples: > > https://stpeter.im/journal/1420.html Unicode defines what characters are confusable (this is arguable imho) so I thought it theoretically possible to achieve this goal. Being confusable should not disqualify as a valid string. i.e. a confusable string should be "valid" and not "disallowed" in terms of Precis classification. For example, both of "ᏚᎢᎵᏋᎢᏋᏒ" and "STPETER" should be valid and they are to be evaluated as confusable. Similarly, Turkish dotless i and the regular I/i should be valid and equivalent. > >>>> username string matching. If the profile doesn't fully specify the >>>> spec but >>>> it's up to the deployment/service policies, I would like the >>>> components to >>>> be able to identify the policies precisely. >>> While I agree with that in principle, it sounds like an >>> interoperability and implementation nightmare (which issue is, I >>> think, what got us the current compromise text). >> I am concerned about interoperability problems that may happen due to >> the ambiguity in the profile spec. Right now, an implementation of >> UsernameIdentifierClass may use arbitrary character mappings. I agree >> the compromise was required, but I think it has introduced the problems >> while partially resolving the other requirement to match the various >> current practices of mapping some characters in username handling. > > As far as I can see, the only alternative to the compromise we've > brokered here is (my understanding of) what John suggests: lock down > the base string classes, effectively disallow profiles, and tell > existing applications to conform to the new rules. If they want > exceptions, then they don't have to use PRECIS. > > In my opinion, that would be slightly at odds with the spirit of how > the PRECIS WG was formed, since all of the Stringprep "customers" in > the room at the NewPrep BoF had existing profiles and wanted to figure > out how to use modern versions of Unicode while supporting as many of > their existing strings/identifiers as possible. If we now tell those > customers that we can't meet their needs, I don't think they will be > particularly happy. But, as John also says, this is about pleasing (or > at least minimizing confusion for) end users. > I think the standard username profile should not disalllow commonly used characters so the "customers'" existing profiles will be valid. Then their individual policies regarding disallowed characters may be handled as a sub-profile or variant. I think it would be desirable to enable identifying the complete specification (ideally registered in an IANA registry) using a compact identifier. Regards, -Dan > Peter > > > > From nobody Thu Sep 18 14:10:48 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA5141A89A4 for ; Thu, 18 Sep 2014 14:10:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xs-ulxthHvHZ for ; Thu, 18 Sep 2014 14:10:38 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6830E1A8980 for ; Thu, 18 Sep 2014 14:10:10 -0700 (PDT) Received: from mx1.yitter.info (nat-08-mht.dyndns.com [216.146.45.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id E27748A031 for ; Thu, 18 Sep 2014 21:10:08 +0000 (UTC) Date: Thu, 18 Sep 2014 17:10:01 -0400 From: Andrew Sullivan To: precis@ietf.org Message-ID: <20140918211001.GE93684@mx1.yitter.info> References: <53FBCC7B.5090700@oracle.com> <53FBE359.3060102@oracle.com> <53FBE4F5.4060804@stpeter.im> <53FBE847.1080305@oracle.com> <5400FB7C.60104@stpeter.im> <540663F4.1040409@oracle.com> <20140903064647.GC40310@mx1.yitter.info> <54074AE8.5090806@oracle.com> <540FA6EE.4050904@stpeter.im> <541B3B0C.2040307@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <541B3B0C.2040307@oracle.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/precis/r-rGhdmzZomxWK4ni5-QLGct1mM Subject: Re: [precis] PRECIS profiles appear underspecified X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 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, 18 Sep 2014 21:10:45 -0000 On Thu, Sep 18, 2014 at 01:05:32PM -0700, Dan Chiba wrote: > Unicode defines what characters are confusable (this is arguable imho) so I > thought it theoretically possible to achieve this goal. Unicode's list is a good start, and it certainly includes the worst cases, but it may not be applicable to every case. My Arabic-using friends tell me that it doesn't solve some of their worries, also. I do not know enough about practical Arabic use to evaluate those claims. A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Tue Sep 23 00:19:01 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 394A51A02FC for ; Mon, 22 Sep 2014 23:35:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YUwoL0IVxztp; Mon, 22 Sep 2014 23:35:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 216FF1A1A2B; Mon, 22 Sep 2014 23:35:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: precis-chairs@tools.ietf.org, draft-ietf-precis-framework@tools.ietf.org, precis@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140923063516.5484.50941.idtracker@ietfa.amsl.com> Date: Mon, 22 Sep 2014 23:35:16 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/precis/7U0cjsqfUg8mb6vW8AYjrujZXmE X-Mailman-Approved-At: Tue, 23 Sep 2014 00:18:57 -0700 Subject: [precis] ID Tracker State Update Notice: X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Sep 2014 06:35:18 -0000 IESG state changed to Approved-announcement to be sent::Revised I-D Needed from Approved-announcement to be sent::AD Followup ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-precis-framework/ From nobody Tue Sep 23 07:47:00 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 542221A86DF for ; Tue, 23 Sep 2014 07:46:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6XdZpdP3-UH8 for ; Tue, 23 Sep 2014 07:46:56 -0700 (PDT) Received: from mail-ig0-f178.google.com (mail-ig0-f178.google.com [209.85.213.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 139CA1A1ADC for ; Tue, 23 Sep 2014 07:46:56 -0700 (PDT) Received: by mail-ig0-f178.google.com with SMTP id r10so4680740igi.11 for ; Tue, 23 Sep 2014 07:46:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=vowc9QcUMG3vlr7u8w36MLJBM5OwQBJIhMRBEFfWTaM=; b=bVQ0A2hlQGmbnsVyw7D0HMAjKsporEVyULiy4nRDpyCJ8Tvuw2p4EBRok5qEPhN3bg Nqq7CyLNaXX+3e5lptzF+frrX6I1Go/5fytor3G0K0YVHMma0ncLJvSh9Rr4KGJNGxjn HSIQHkPg5yqeaR4UWH0ezVGbsWWLa2PsyzgPTlq5uK7nWiw/z1BZ80uCiqwAeh4nXlRW V6pH8ZIodiHZ/ZPPvxwPBxsRXtQ8kUyPVEqJ1QaCHwXaObOTxXJiQWf284ZM92lz9IRf cmyvz4ELxvs/aCqpeglD4FLP7yxf3wceMyeAmzqMojZGsoN4YCoC4sUZEP27PMym3zpI wUBw== X-Gm-Message-State: ALoCoQl5jebEot8a0x0+5p5/ljjIHw5c4cSdXHjnIquUu2X4TKpu9LTW9rnRUpAcnga46fzhzziz X-Received: by 10.50.147.38 with SMTP id th6mr23093889igb.31.1411483615377; Tue, 23 Sep 2014 07:46:55 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id k6sm1821421ige.13.2014.09.23.07.46.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 23 Sep 2014 07:46:54 -0700 (PDT) Message-ID: <542187DE.1040002@andyet.net> Date: Tue, 23 Sep 2014 08:46:54 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: precis@ietf.org References: <20140923063516.5484.50941.idtracker@ietfa.amsl.com> In-Reply-To: <20140923063516.5484.50941.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/precis/0coRsxesP521ElwIxIZJhoUQgbw Subject: Re: [precis] ID Tracker State Update Notice: X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 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 Sep 2014 14:46:58 -0000 On 9/23/14, 12:35 AM, IETF Secretariat wrote: > IESG state changed to Approved-announcement to be sent::Revised I-D Needed from Approved-announcement to be sent::AD Followup > ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-precis-framework/ Yes, I still need to address and incorporate the less major (I won't say minor!) feedback from John's IETF Last Call message: http://www.ietf.org/mail-archive/web/precis/current/msg00749.html I'll endeavor to do that this week or next. Peter