From stpeter@stpeter.im Mon May 7 13:45:16 2012 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5424921F849D for ; Mon, 7 May 2012 13:45:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.535 X-Spam-Level: X-Spam-Status: No, score=-103.535 tagged_above=-999 required=5 tests=[AWL=1.064, BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a3Vhk5VhKAWi for ; Mon, 7 May 2012 13:45:15 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 6140521F8496 for ; Mon, 7 May 2012 13:45:15 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id BC3CF40058 for ; Mon, 7 May 2012 15:00:29 -0600 (MDT) Message-ID: <4FA83459.1080909@stpeter.im> Date: Mon, 07 May 2012 14:45:13 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "precis@ietf.org" References: <4F756143.2080606@stpeter.im> <4F848359.1080105@stpeter.im> <4F84B2F1.3020807@stpeter.im> In-Reply-To: <4F84B2F1.3020807@stpeter.im> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [precis] LetterDigits X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 20:45:16 -0000 On 4/10/12 4:23 PM, Peter Saint-Andre wrote: > On 4/10/12 1:00 PM, Peter Saint-Andre wrote: >> The context for this discussion was the fact that the LetterDigits >> category (which we borrow from RFC 5892) disallows codepoints with the >> properties listed below, so we have an open issue about whether to allow >> such codepoints in the FreeClass. >> >> My take is that the FreeClass is intended to be extremely inclusive, and >> that disallowing titlecase letters, letter numbers, other numbers, and >> enclosing marks is inconsistent with that intent. > > Questions of an InBetweenClass aside, would folks here have concerns > with defining an OtherLetterDigits category for use in the FreeClass? Seeing no objections, I'll go ahead with this approach so that the FreeClass can be truly free. ;-) Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Mon May 7 16:35:15 2012 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E59A821F8692 for ; Mon, 7 May 2012 16:35:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FoDduLnSiOGL for ; Mon, 7 May 2012 16:35:15 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id D535521F8670 for ; Mon, 7 May 2012 16:35:14 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id F3A0240058 for ; Mon, 7 May 2012 17:50:29 -0600 (MDT) Message-ID: <4FA85C31.5020009@stpeter.im> Date: Mon, 07 May 2012 17:35:13 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "precis@ietf.org" X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: [precis] spaces in names, and compound names? X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 23:35:16 -0000 [Sorry about the length of this message.] In Paris, we had a 20-minute discussion about the inclusion of space characters in names. Here are some notes I just made based on listening to the recording. [1] ### Alexey Melnikov raised an issue about SASLprepbis needing ASCII space in simple user names (and also perhaps for LDAP). One approach would be to allow space in the NameClass and tell protocols that don't want it in usernames to forbid the space. Marc Blanchet voiced a preference for defining a common class that would be usable by the majority of PRECIS customers, and noted that so far (except for SASLprepbis) they don't seem to need space. Andrew Sullivan pointed out that in some locales the "space bar" on a keyboard can result in generation not of ASCII space but of a zero width non joiner (ZWNJ) and voiced concern that allowing space might be the thin edge of a wedge leading to significant problems later on. Pete Resnick noted that the left hand side of an email address can contain all sorts of things if it is enclosed in quotes, and leaned toward saying that some application protocols use something like FreeClass or a subclass thereof because it appears that they might not need just ASCII space but all sorts of interesting characters. Alexey Melnikov noted that for SASLprepbis we only need ASCII space. Joe Hildebrand pointed out that we might provide advice to protocols regarding which codepoints are safe to use. Marc Blanchet suggested formulating a safe class that would be less exclusive than the (currently very restricted) NameClass. Peter Saint-Andre concurred, adding that it would be better to do that than to make the NameClass more inclusive. Andrew Sullivan went further and suggested that the NameClass just needs to be a good class for names, not a class that can be used to represent every possible name. He suggested that if you have something like email that is less restrictive, then use FreeClass and subclass it carefully yourself. His conclusion was that putting spaces in the NameClass would be a bad idea. Joe Hildebrand suggested other options: (1) say spaces are bad so don't use them and they are disallowed in NameClass or (2) spaces aren't so bad, allow them in all protocols. [Note: Discussion of superclassing elided because we decided against that.] Pete Resnick noted that the working group concluded earlier that spaces are to be avoided in names because sometimes they are visible and sometimes they are not etc. ("spaces are the sorts of things that would get names into trouble"). Andrew Sullivan brought up the Unicode confusables table [2] for spaces and pointed out that there is no way to tell the difference between, say, an em-space and a space; as a result, he concluded that this is a disaster because we don't control the input method. Joe Hildebrand said another approach would be to come back to the SASL folk and say "this is a bad idea, don't do it". He asked: how widely used are spaces in simple user names, and can't we tell folks to clean up their databases (just as we'll need to do in XMPP)? Marc Blanchet suggested that we could define an "unsafe name class" which would include spaces, with big warnings not to use it. Pete Resnick noted that we could go to the security area and say "we're planning to remove spaces from our internationalized names spec, what would break?" Because it might be safer to clean up existing code and databases than to allow spaces in usernames. David Black noted that if we get around to tackling NFS, spaces would become relevant. However, fileneames in NFC are really weird and probably don't fit in the PRECIS framework. Marc Blanchet pointed out that NFS would probably need to use FreeClass, not NameClass. The conclusion was that we needed to follow up with our friends in the Security Area. ### Since the Paris meeting, I have indeed done just that: http://www.ietf.org/mail-archive/web/kitten/current/msg03054.html Later messages in that thread are here: http://www.ietf.org/mail-archive/web/kitten/current/msg03055.html http://www.ietf.org/mail-archive/web/kitten/current/msg03056.html http://www.ietf.org/mail-archive/web/kitten/current/msg03057.html http://www.ietf.org/mail-archive/web/kitten/current/msg03058.html http://www.ietf.org/mail-archive/web/kitten/current/msg03059.html http://www.ietf.org/mail-archive/web/kitten/current/msg03060.html http://www.ietf.org/mail-archive/web/kitten/current/msg03061.html http://www.ietf.org/mail-archive/web/kitten/current/msg03073.html http://www.ietf.org/mail-archive/web/kitten/current/msg03074.html As you can see, there was some pushback about removing spaces from SASL simple user names. However, I did not ask the question I heard from Pete Resnick at the end of that discussion in Paris, which was: "what would break if we did this?" We seem to have anecdotal evidence of some usage of spaces in simple user names, but we don't seem to know how widespread that usage is, nor what would break if we defined NameClass to exclude space (and note that, among other things, SASLprepbis could subclass the FreeClass in order to meet the needs of SASLprepbis -- they don't absolutely need to use NameClass just because they have a construct called a simple user *name* -- I think there's a lack of precision about these matters in the thread I pointed to above). Another approach I've been thinking about would be to define (in the framework document or in SASLprepbis) a class that we could call CompoundNameClass. A compound name would start with a name (i.e., an instance of the NameClass) and then contain one or more instances of the NameClass separated from the other instances by a single ASCII space, ending with an instance of the NameClass (thus it could not begin or end with a space and could not contain multiple spaces in a row). This CompoundNameClass would be less safe than the NameClass, but it would explicitly allow only U+0020 -- all other spacelike codepoints would need to be mapped to U+0020. We'd still have the same challenges with regard to input methods and possible confusion that were voiced during the discussion in Paris, but from a protocol perspective only U+0020 would be allowed on the wire. I'd like to discuss that option a bit before taking this topic back to the KITTEN WG. Peter [1] You can listen to the discussion yourself at around the 35-minute mark of the audio recording, which is available here: http://www.ietf.org/audio/ietf83/ietf83-253-20120329-1256-pm.mp3 [2] See the Unicode confusables.txt file for this table: 180E ; 0020 ; SL #* ( <180e> → ) MONGOLIAN VOWEL SEPARATOR → SPACE # 2028 ; 0020 ; SL #* ( → ) LINE SEPARATOR → SPACE # 2029 ; 0020 ; SL #* ( → ) PARAGRAPH SEPARATOR → SPACE # 2000 ; 0020 ; SL #* (   → ) EN QUAD → SPACE # 2001 ; 0020 ; SL #* (   → ) EM QUAD → SPACE # 2002 ; 0020 ; SL #* (   → ) EN SPACE → SPACE # 2003 ; 0020 ; SL #* (   → ) EM SPACE → SPACE # 2004 ; 0020 ; SL #* (   → ) THREE-PER-EM SPACE → SPACE # 2005 ; 0020 ; SL #* (   → ) FOUR-PER-EM SPACE → SPACE # 2006 ; 0020 ; SL #* (   → ) SIX-PER-EM SPACE → SPACE # 2008 ; 0020 ; SL #* (   → ) PUNCTUATION SPACE → SPACE # 2009 ; 0020 ; SL #* (   → ) THIN SPACE → SPACE # 200A ; 0020 ; SL #* (   → ) HAIR SPACE → SPACE # 205F ; 0020 ; SL #* (   → ) MEDIUM MATHEMATICAL SPACE → SPACE # 00A0 ; 0020 ; SL #* ( → ) NO-BREAK SPACE → SPACE # 2007 ; 0020 ; SL #* (   → ) FIGURE SPACE → SPACE # 202F ; 0020 ; SL #* (   → ) NARROW NO-BREAK SPACE → SPACE # 1680 ; 0020 ; SL #* (   → ) OGHAM SPACE MARK → SPACE # From stpeter@stpeter.im Mon May 7 19:50:57 2012 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA16121F84D2 for ; Mon, 7 May 2012 19:50:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.547 X-Spam-Level: X-Spam-Status: No, score=-102.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7blc41M3KVsj for ; Mon, 7 May 2012 19:50:57 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 4F1DC21F84AE for ; Mon, 7 May 2012 19:50:57 -0700 (PDT) Received: from [192.168.0.9] (unknown [216.17.175.160]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A6BBB40058 for ; Mon, 7 May 2012 21:06:12 -0600 (MDT) Message-ID: <4FA88A10.2030903@stpeter.im> Date: Mon, 07 May 2012 20:50:56 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "precis@ietf.org" X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [precis] the Exceptions category X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 02:50:58 -0000 RFC 5892 defines a category called Exceptions, which lists codepoints whose assignment differs from what the assignment would have been based solely on the core property value. For example, while working on the PRECIS codepoint table I just found U+0F0B (TIBETAN MARK INTERSYLLABIC TSHEG), which has a core property value of Po ("Punctuation, other") and which thus would have been DISALLOWED in IDNA2008 if it had not been explicitly placed in the Exceptions category. Unfortunately, the decisions of the IDNA2008 team with regard to these exceptions are not documented in RFC 5892 or elsewhere (AFAIK), so it's not easy to understand whether it would be best for PRECIS to follow IDNA2008 here or instead to base our assignments on the core property values for some or all of the codepoints in the Exceptions category. (Using the same example, if we follow IDNA2008 then U+0F0B would be PVALID, whereas if we base assignment on the core property value then this codepoint would be FREE_PVAL and NAME_DIS.) I understand the reasoning behind codepoints like sharp S and Greek final sigma because they were extensively discussed on the IDNA list, but other codepoints were not as controversial. I suppose the safest course would be to follow IDNA2008 here. The second-safest course would be to base all assignments on the core property value. The least safe course would be revisiting each codepoint individually and thus defining a PrecisExceptions table that differs in subtle ways from the IDNA2008 Exceptions table. Peter -- Peter Saint-Andre https://stpeter.im/ From jefsey@gmail.com Tue May 8 09:34:33 2012 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8ED21F8499 for ; Tue, 8 May 2012 09:34:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UU9UpF0CyQIt for ; Tue, 8 May 2012 09:34:32 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8875221F8495 for ; Tue, 8 May 2012 09:34:32 -0700 (PDT) Received: by dacx6 with SMTP id x6so87538dac.31 for ; Tue, 08 May 2012 09:34:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=G1HCqSDggF03chbUBwFUKC0VD/ByOWLlWJj5yD/Fhfg=; b=tUexU33NS4QNTUAXrDTFlFYnlSxJicAMDeN0lD4WVUnLQojwx0B84yyldd782Qr+iq Lh64rQFHTdVljFA6gFmfTGRm7n02EeqOIAGk0DQtKBJVYeD7OpD6hQqdeCabHZwJAo+R Y4owOc3nxWxigxNjj1J4F9ohi6PTqXNoEnvlKegZ/OGi+byugYvOGl6DpYoPlHfYChPI kZhgFHalSOsoJW4NTrh+qzHPRgCkeNKlqjMZl+CJ1PbcXhv3i9kMYATpX0sBHtg/Qxjq WzAs1cKoIKGcIKfDtnAUf6XfqAjThFvboadbEMNbt+5nKXo2eHMv9RltbdGP/ZLYViXw qs+Q== MIME-Version: 1.0 Received: by 10.68.235.69 with SMTP id uk5mr2758583pbc.10.1336494872271; Tue, 08 May 2012 09:34:32 -0700 (PDT) Sender: jefsey@gmail.com Received: by 10.68.191.168 with HTTP; Tue, 8 May 2012 09:34:31 -0700 (PDT) In-Reply-To: <4FA88A10.2030903@stpeter.im> References: <4FA88A10.2030903@stpeter.im> Date: Tue, 8 May 2012 18:34:31 +0200 X-Google-Sender-Auth: nFYPkbmnJuJmdiDBlxf1IVXSY9A Message-ID: From: JFC Morfin To: Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 Cc: "precis@ietf.org" Subject: Re: [precis] the Exceptions category X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 16:34:33 -0000 2012/5/8, Peter Saint-Andre : > I suppose the safest course would be to follow IDNA2008 here. The > second-safest course would be to base all assignments on the core > property value. The least safe course would be revisiting each codepoint > individually and thus defining a PrecisExceptions table that differs in > subtle ways from the IDNA2008 Exceptions table. Peter, IDNA is actually two things. 1. the way the Internet technology addresses the linguistic diversity in using ASCII in the DNS. 2. as a result, how the external world, is to assume the Internet technology interfaces the linguistic diversity. Hence, 1. non-Internet technology applications of any nature will take IDNA2008 as the implied multilinguistic model. 2. non-DNS internet protocols should consider that external protocols and applications will expect they comply with IDNA2008. 3. non-DNS internet protocols will expect that DNS and other non-DNS protocols will comply with IDNA2008. Now, 1. it seems advisable to follow IDNA2008 as a default. 2. if there are cases where it looks advisable not to follow IDNA2008 internally 2.1. either protocol external I/O should comply with IDNA2008 2.2. or protocol special I/O with an other protocols could be devised, provided the group of the two (or possibly more) protocols externally comply with IDNA2008. This last point is noteworthy. In the case of my Internet+ Draft, there will be IDNA2008 extensions (IDNA2008+) to support orthotypography and variants. However, the Internet and the Internet+ are different strata (goup of layers) with my documented IUI (intelligent use interface) in between. The IUI will take care of the interface between the Internet IDNA2008 and the Internet+ IDNA2008+. As an exemple: let suppose that upper cases are supported by the ML-DNS (multilayer DNS) as the format "A" > "^a" (^ being a code point to determine), the resulting name will be a punycoded ASCII transparent to the Internet internal protocols. As a reminder, Internet+ stands for Internet PLUS (plugged layers on the user side), i.e. added intellingent network layers extending the OSI model as documented by RFC 1958 which stipulates that everything which is not end to end dump protocols is to be addressed at the fringe. The internet+ is fringe to fringe and results from the RFC 5895 consensus which permitted the IDNA2008 consensus, introducing subsidiarity by the users over a stable sustainable internal Internet technology as a response to the distributed diversity of the Internet external world. A current operational first Internet+ experimentation is Google+. Best jfc From yoshiro.yoneya@jprs.co.jp Tue May 8 18:24:28 2012 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AF2A9E800E for ; Tue, 8 May 2012 18:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a703rBaYWnQx for ; Tue, 8 May 2012 18:24:27 -0700 (PDT) Received: from off-send01.tyo.jprs.co.jp (off-send01.tyo.jprs.co.jp [IPv6:2001:df0:8:17::10]) by ietfa.amsl.com (Postfix) with ESMTP id 942A79E801A for ; Tue, 8 May 2012 18:24:19 -0700 (PDT) Received: from off-sendsmg01.tyo.jprs.co.jp (off-sendsmg01.tyo.jprs.co.jp [172.18.8.32]) by off-send01.tyo.jprs.co.jp (8.13.8/8.13.8) with ESMTP id q491OHIJ028051 for ; Wed, 9 May 2012 10:24:17 +0900 X-AuditID: ac120820-b7f4d6d000000ccc-e0-4fa9c7413267 Received: from NOTE550 (off-cpu04.tyo.jprs.co.jp [172.18.4.14]) by off-sendsmg01.tyo.jprs.co.jp (Symantec Messaging Gateway) with SMTP id B3.F2.03276.147C9AF4; Wed, 9 May 2012 10:24:17 +0900 (JST) Date: Wed, 9 May 2012 10:24:19 +0900 From: Yoshiro YONEYA To: precis@ietf.org Message-Id: <20120509102419.4e8188d1.yoshiro.yoneya@jprs.co.jp> X-Mailer: Sylpheed 3.1.4 (GTK+ 2.10.14; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCIsWRmVeSWpSXmKPExsWyRoiFT9fx+Ep/g+cThSx2ff/D6sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujDMXAwpWMVdsPm7TwHibqYuRk0NCwERixuJDULaYxIV769m6 GLk4hASOM0rc2nSWBSTBIqAicXvSDjCbTcBA4tey32ANIgLCErduL2QFsYUFLCUWvL7PDmLz CthLvPm2kh1iqIXE0/MngOo5gOKCEn93CIOEmQW0JB7+usUCYctLbH87h3kCI88shKpZSKpm IalawMi8ilEmPy1Ntzg1L6U4N93AUK+kMl8vq6CoWC8ZRG9iBAcKh8IOxhmnDA4xCnAwKvHw 9uxa6S/EmlhWXJl7iFGSg0lJlHf+HqAQX1J+SmVGYnFGfFFpTmrxIUYJDmYlEd5Z6kA53pTE yqrUonyYlDQHi5I47/GzO/yEBNITS1KzU1MLUotgsjIcHEoSvD3HgBoFi1LTUyvSMnNKENJM HJwgw3mAhl8BqeEtLkjMLc5Mh8ifYpSUEudtA0kIgCQySvPgel8xigO9IMzbCpLlAUY9XNcr oIFMQAOnHQYbWJKIkJJqYNwaHm3wJf5Ssf5p7Zx4LUHbQwEvqplsr6SctJk0LeDex/CLkoKH Ob6sMnl64YPInzqv+7mP3y3tnM3CzbPO777t31Xfly+dN39OgOSV2drsxVqhDIKTb85a+vEk s/T7ihTV1wevzJxXcuRKmPMUWzHR6HeC10s2z14qmMJ58ur2Nft0tn/ieqKuxFKckWioxVxU nAgAGiEHbLcCAAA= Subject: [precis] WGLC: draft-ietf-precis-problem-statement-05.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 01:24:28 -0000 Dear all, This message starts two weeks Working Group Last Call (WGLC) on draft-ietf-precis-problem-statement-05.txt (Stringprep Revision Problem Statement). Please review the document and send comments to the list, the co-chairs, or the authors (draft-ietf-precis-problem-statement.all@tools.ietf.org) by the end of WGLC. The WGLC will end on Friday, May 25th. Regards, -- Marc & Yoshiro, co-chairs From stpeter@stpeter.im Tue May 8 21:37:13 2012 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E124B11E8074 for ; Tue, 8 May 2012 21:37:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.552 X-Spam-Level: X-Spam-Status: No, score=-102.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EZs4MDD7s3pn for ; Tue, 8 May 2012 21:37:13 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id EACB911E808A for ; Tue, 8 May 2012 21:37:12 -0700 (PDT) Received: from [192.168.0.9] (unknown [216.17.175.160]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id ED16240058; Tue, 8 May 2012 22:52:31 -0600 (MDT) Message-ID: <4FA9F473.2010802@stpeter.im> Date: Tue, 08 May 2012 22:37:07 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Yoshiro YONEYA References: <20120509102419.4e8188d1.yoshiro.yoneya@jprs.co.jp> In-Reply-To: <20120509102419.4e8188d1.yoshiro.yoneya@jprs.co.jp> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: precis@ietf.org Subject: Re: [precis] WGLC: draft-ietf-precis-problem-statement-05.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 04:37:14 -0000 On 5/8/12 7:24 PM, Yoshiro YONEYA wrote: > Dear all, > > This message starts two weeks Working Group Last Call (WGLC) on > draft-ietf-precis-problem-statement-05.txt (Stringprep Revision > Problem Statement). Overall I think this document is in good shape. I have a few small comments. 1. In the Introduction, I think it would be useful to explain a bit more clearly the difference between an inclusion-based approach (only the codepoints that are explicitly included will be allowed) and an exclusion-based approach (all codepoints are allowed unless explicitly excluded). There's text about this in Section 4.2.4, so perhaps we could simply move that up. 2. Section 4.2.2 quotes UAX15. To provide a bit more context for the statement about NFKC perhaps not being appropriate for comparing human names, I suggest adding a sentence like the following after that quote: "In general, it can be said that NFKC is more aggressive about finding matches between codepoints than NFC." 3. In Section 4.2.2, spell out "LDH" on first use (and perhaps cite one of the DNS specs on the topic). 4. Section 5 states that "Recommendations for handling protocol incompatibilities resulting from changes to Unicode are required", but it seems to me that this is a matter for application protocols that use the replacement for stringprep, not the replacement itself. Peter -- Peter Saint-Andre https://stpeter.im/ From simon@josefsson.org Wed May 9 02:25:20 2012 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C6B821F84D5 for ; Wed, 9 May 2012 02:25:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.821 X-Spam-Level: X-Spam-Status: No, score=-99.821 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id orqtSN951ouf for ; Wed, 9 May 2012 02:25:19 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id E858921F85BE for ; Wed, 9 May 2012 02:25:18 -0700 (PDT) Received: from [192.168.1.42] (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q499P9II008396 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT) for ; Wed, 9 May 2012 11:25:10 +0200 Message-ID: <1336555508.11103.33.camel@latte> From: Simon Josefsson To: precis@ietf.org Date: Wed, 09 May 2012 11:25:08 +0200 In-Reply-To: <20120509102419.4e8188d1.yoshiro.yoneya@jprs.co.jp> References: <20120509102419.4e8188d1.yoshiro.yoneya@jprs.co.jp> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean Subject: Re: [precis] WGLC: draft-ietf-precis-problem-statement-05.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 09:25:20 -0000 Hi! Here is my review of the document. I think it is is in pretty good shape, I have one major concern but I'm sure it can be resolved. /Simon MAJOR: *) Section 4.3.4 specify three classes of strings. As a naive reader that tries to read this document as an introduction, I cannot really follow how you got to those three categories from the rest of the document. Are you trying to match the identifier types discussed in 4.1.1? If so, I don't think the names are very well chosen. I think some more motivational text around how you get to these categories would be useful. They appear to be quite guiding of you form the rest of the technical work (compare appendix A/B). MINOR: *) I'm having trouble parsing the first sentence of the abstract: Using Unicode codepoints in protocol strings that expect comparison with other strings requires preparation of the string that contains the Unicode codepoints. Isn't there something missing here? I.e., something like "expect comparison to work" instead of "expect comparison". Further, I don't think the statement is accurate: comparison work when it is implemented correctly (i.e., Unicode and context aware) -- what will not work is for example _binary_ comparison, which is what I think you are getting at. *) This sentence in the abstract: Internationalizing Domain Names in Applications (IDNA2003) defined and used Stringprep and Nameprep. suggests IDNA2003 was called IDNA2003 at the time. May I suggest s/IDNA2003/here called IDNA2003/ instead? A reader familiar only with RFC 3490 etc may be confused by the term IDNA2003, and at this point of this document the IDNA2008 concepts have not been introduced yet. The same applies to the introduction section where the term IDNA2003 is used without introduction, and before the IDNA2008 documents are referenced. *) The document refers to some URLs like this: However, a review [1] of these protocol specifications found that ... [1] I suspect the RFC Editor will require normal attribution and titles. Looking through these references, they all seem quite easy to fix. *) Section 3 reads: The consensus [4] of the BOF attendees is that it would be highly desirable to have a replacement of Stringprep, with similar characteristics to IDNA2008. I am hoping this discussion and consensus guaging went back to the list. Usually, BOFs doesn't make direct decisions that have bearing on IETF documents. *) Section 4.2.4 contains this observation: IDNA2008 may be a poor model for what other protocols ought to do in this case, because it is designed to support an old protocol that is designed to operate on the scale of the entire Internet. Moreover, IDNA2008 is intended to be deployed without any change to the base DNS protocol. Other protocols may aim at deployment in more local environments, or may have protocol version negotiation built in. I think this is an important observation, and one that applies to almost all topics of IDNA2008 vs PRECIS, and not only the topic discussed in section 4.2.4, i.e., prohibited characters. Could this be moved or duplicated at a more high-level? When I look, only the Introduction section seems appropriate, but there may be other places too. A more general thought here: I'd hate to see new protocols use sub-optimal Unicode behaviour just because they re-use IDNA2008/PRECIS that have several considerations for older protocols and backwards compatibility. Possibly there is room for some recommendations on what new protocols should do as the state-of-the-art. I'm not convinced this is easy to infer from the PRECIS work today. *) Accordingly, as IDNA2008,a Stringprep replacement that intends to be ^ typo, insert SPC *) Spell out 'i18n': o Protocols share similar characteristics of strings. Therefore, defining i18n preparation algorithms for the smallest set of string classes may be sufficient for most cases, providing coherence among a set of related protocols or protocols where identifiers are exchanged. /Simon From stpeter@stpeter.im Wed May 9 08:00:52 2012 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 720DA11E807F for ; Wed, 9 May 2012 08:00:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.554 X-Spam-Level: X-Spam-Status: No, score=-102.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mx3lTNVYAj2v for ; Wed, 9 May 2012 08:00:51 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id BD73A11E80AA for ; Wed, 9 May 2012 08:00:51 -0700 (PDT) Received: from [192.168.0.9] (unknown [216.17.175.160]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 15B2A40058; Wed, 9 May 2012 09:16:12 -0600 (MDT) Message-ID: <4FAA86A4.2030604@stpeter.im> Date: Wed, 09 May 2012 09:00:52 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Simon Josefsson References: <20120509102419.4e8188d1.yoshiro.yoneya@jprs.co.jp> <1336555508.11103.33.camel@latte> In-Reply-To: <1336555508.11103.33.camel@latte> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: precis@ietf.org Subject: Re: [precis] WGLC: draft-ietf-precis-problem-statement-05.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 15:00:52 -0000 On 5/9/12 3:25 AM, Simon Josefsson wrote: > Hi! Here is my review of the document. I think it is is in pretty good > shape, I have one major concern but I'm sure it can be resolved. > > /Simon > > MAJOR: > > *) Section 4.3.4 specify three classes of strings. As a naive reader > that tries to read this document as an introduction, I cannot really > follow how you got to those three categories from the rest of the > document. Are you trying to match the identifier types discussed in > 4.1.1? If so, I don't think the names are very well chosen. I think > some more motivational text around how you get to these categories > would be useful. They appear to be quite guiding of you form the rest > of the technical work (compare appendix A/B). Hi Simon, Yes, I think it might be better to let the framework document make an argument for those three string classes, rather than put it in the problem statement. Peter -- Peter Saint-Andre https://stpeter.im/ From ajs@anvilwalrusden.com Wed May 9 10:22:21 2012 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 052D711E80AB for ; Wed, 9 May 2012 10:22:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hxsp2WcKbSne for ; Wed, 9 May 2012 10:22:20 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 44A4211E80A3 for ; Wed, 9 May 2012 10:22:19 -0700 (PDT) Received: from mail.yitter.info (nat-05-mht.dyndns.com [216.146.45.244]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id A26891ECB41D for ; Wed, 9 May 2012 17:22:18 +0000 (UTC) Date: Wed, 9 May 2012 13:22:09 -0400 From: Andrew Sullivan To: precis@ietf.org Message-ID: <20120509172204.GF11930@mail.yitter.info> References: <20120509102419.4e8188d1.yoshiro.yoneya@jprs.co.jp> <1336555508.11103.33.camel@latte> <4FAA86A4.2030604@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FAA86A4.2030604@stpeter.im> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [precis] WGLC: draft-ietf-precis-problem-statement-05.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 17:22:21 -0000 Hi Simon and Peter, Thanks for the reviews! One question: On Wed, May 09, 2012 at 09:00:52AM -0600, Peter Saint-Andre wrote: > On 5/9/12 3:25 AM, Simon Josefsson wrote: > > *) Section 4.3.4 specify three classes of strings. As a naive reader > > that tries to read this document as an introduction, I cannot really > > follow how you got to those three categories from the rest of the > > document. > Yes, I think it might be better to let the framework document make an > argument for those three string classes, rather than put it in the > problem statement. Is the suggestion here to remove the string classes entirely from this document, and leave it to the framework? Thanks, A -- Andrew Sullivan ajs@anvilwalrusden.com From stpeter@stpeter.im Wed May 9 10:30:46 2012 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3F6211E8072 for ; Wed, 9 May 2012 10:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.55 X-Spam-Level: X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b3SVkpRiq5BN for ; Wed, 9 May 2012 10:30:45 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 9EF7111E80A3 for ; Wed, 9 May 2012 10:30:45 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 7833140058; Wed, 9 May 2012 11:46:06 -0600 (MDT) Message-ID: <4FAAA9C4.4020201@stpeter.im> Date: Wed, 09 May 2012 11:30:44 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Andrew Sullivan References: <20120509102419.4e8188d1.yoshiro.yoneya@jprs.co.jp> <1336555508.11103.33.camel@latte> <4FAA86A4.2030604@stpeter.im> <20120509172204.GF11930@mail.yitter.info> In-Reply-To: <20120509172204.GF11930@mail.yitter.info> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: precis@ietf.org Subject: Re: [precis] WGLC: draft-ietf-precis-problem-statement-05.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 17:30:46 -0000 On 5/9/12 11:22 AM, Andrew Sullivan wrote: > Hi Simon and Peter, > > Thanks for the reviews! One question: > > On Wed, May 09, 2012 at 09:00:52AM -0600, Peter Saint-Andre wrote: >> On 5/9/12 3:25 AM, Simon Josefsson wrote: > >>> *) Section 4.3.4 specify three classes of strings. As a naive reader >>> that tries to read this document as an introduction, I cannot really >>> follow how you got to those three categories from the rest of the >>> document. > >> Yes, I think it might be better to let the framework document make an >> argument for those three string classes, rather than put it in the >> problem statement. > > Is the suggestion here to remove the string classes entirely from this > document, and leave it to the framework? I think so. Let the problem statement define the problem and the framework define the solution. From simon@josefsson.org Wed May 9 11:00:18 2012 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E3A611E80A2 for ; Wed, 9 May 2012 11:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.824 X-Spam-Level: X-Spam-Status: No, score=-99.824 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0uacAz-gqXNY for ; Wed, 9 May 2012 11:00:17 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id 43FAD11E8081 for ; Wed, 9 May 2012 11:00:17 -0700 (PDT) Received: from latte (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q49I03L8031010 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 9 May 2012 20:00:05 +0200 X-Hashcash: 1:22:120509:ajs@anvilwalrusden.com::OjGfoO4uA5GJtL4A:tRc7 X-Hashcash: 1:22:120509:precis@ietf.org::46AnE11uBL5RZxda:HYT From: Simon Josefsson To: Andrew Sullivan References: <20120509102419.4e8188d1.yoshiro.yoneya@jprs.co.jp> <1336555508.11103.33.camel@latte> <4FAA86A4.2030604@stpeter.im> <20120509172204.GF11930@mail.yitter.info> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt Date: Wed, 09 May 2012 20:00:02 +0200 In-Reply-To: <20120509172204.GF11930@mail.yitter.info> (Andrew Sullivan's message of "Wed, 9 May 2012 13:22:09 -0400") Message-ID: <87fwb9kzfh.fsf@latte.josefsson.org> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean Cc: precis@ietf.org Subject: Re: [precis] WGLC: draft-ietf-precis-problem-statement-05.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 18:00:18 -0000 Andrew Sullivan writes: > Hi Simon and Peter, > > Thanks for the reviews! One question: > > On Wed, May 09, 2012 at 09:00:52AM -0600, Peter Saint-Andre wrote: >> On 5/9/12 3:25 AM, Simon Josefsson wrote: > >> > *) Section 4.3.4 specify three classes of strings. As a naive reader >> > that tries to read this document as an introduction, I cannot really >> > follow how you got to those three categories from the rest of the >> > document. > >> Yes, I think it might be better to let the framework document make an >> argument for those three string classes, rather than put it in the >> problem statement. > > Is the suggestion here to remove the string classes entirely from this > document, and leave it to the framework? That works for me. I'm hoping it is well explained in the framework. :-) Thanks, /Simon From stpeter@stpeter.im Wed May 9 13:01:17 2012 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1FBC11E80CC for ; Wed, 9 May 2012 13:01:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y+YQUDbag7To for ; Wed, 9 May 2012 13:01:17 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 2F8E511E8079 for ; Wed, 9 May 2012 13:01:17 -0700 (PDT) Received: from [192.168.0.9] (unknown [216.17.175.160]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id C32504005B; Wed, 9 May 2012 14:16:37 -0600 (MDT) Message-ID: <4FAACD0A.4070003@stpeter.im> Date: Wed, 09 May 2012 14:01:14 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Simon Josefsson References: <20120509102419.4e8188d1.yoshiro.yoneya@jprs.co.jp> <1336555508.11103.33.camel@latte> <4FAA86A4.2030604@stpeter.im> <20120509172204.GF11930@mail.yitter.info> <87fwb9kzfh.fsf@latte.josefsson.org> In-Reply-To: <87fwb9kzfh.fsf@latte.josefsson.org> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: precis@ietf.org Subject: Re: [precis] WGLC: draft-ietf-precis-problem-statement-05.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 20:01:17 -0000 On 5/9/12 12:00 PM, Simon Josefsson wrote: > Andrew Sullivan writes: > >> Hi Simon and Peter, >> >> Thanks for the reviews! One question: >> >> On Wed, May 09, 2012 at 09:00:52AM -0600, Peter Saint-Andre wrote: >>> On 5/9/12 3:25 AM, Simon Josefsson wrote: >> >>>> *) Section 4.3.4 specify three classes of strings. As a naive reader >>>> that tries to read this document as an introduction, I cannot really >>>> follow how you got to those three categories from the rest of the >>>> document. >> >>> Yes, I think it might be better to let the framework document make an >>> argument for those three string classes, rather than put it in the >>> problem statement. >> >> Is the suggestion here to remove the string classes entirely from this >> document, and leave it to the framework? > > That works for me. I'm hoping it is well explained in the framework. :-) I'm pushing hard to submit a revised framework I-D soon! Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Wed May 9 18:50:29 2012 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 862BA11E80E4 for ; Wed, 9 May 2012 18:50:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.551 X-Spam-Level: X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g1i-jbuqAKK5 for ; Wed, 9 May 2012 18:50:29 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id E547A11E80E3 for ; Wed, 9 May 2012 18:50:28 -0700 (PDT) Received: from [192.168.0.9] (unknown [216.17.175.160]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id F160E4005B for ; Wed, 9 May 2012 20:05:50 -0600 (MDT) Message-ID: <4FAB1EE3.5060007@stpeter.im> Date: Wed, 09 May 2012 19:50:27 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "precis@ietf.org" X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [precis] codepoint table X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 01:50:29 -0000 I'm almost finished with the codepoint table. Basically my process has been to copy over the codepoint table from RFC 5892 and update it in accordance with the new PRECIS rules and Unicode 6.1 UnicodeData.txt. While completing this work, I realize it would have been very helpful for the IDNA table to contain a column describing the reason for each assignment (e.g., codepoints 1100..115F are DISALLOWED in IDNA2008 because they trigger the OldHangulJamo (I) rule). This is more work for the person making the codepoint table (c'est moi), but it provides better traceability, so I am thinking about adding this information to the PRECIS codepoint table. Let me know if you have concerns. :) Peter -- Peter Saint-Andre https://stpeter.im/ From paf@frobbit.se Wed May 9 21:35:09 2012 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1531F11E808E for ; Wed, 9 May 2012 21:35:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cYS0z+D8N6bW for ; Wed, 9 May 2012 21:35:08 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id 3C8CB11E8087 for ; Wed, 9 May 2012 21:35:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 65DFF13BF5368; Thu, 10 May 2012 06:35:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ShdDxqne5Zuc; Thu, 10 May 2012 06:35:05 +0200 (CEST) Received: from [192.168.125.65] (h85-8-16-97.static.se.alltele.net [85.8.16.97]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id B578F13BF5357; Thu, 10 May 2012 06:35:05 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <4FAB1EE3.5060007@stpeter.im> Date: Thu, 10 May 2012 06:35:02 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <24F7F85B-1434-415E-962D-F9FC52879BAD@frobbit.se> References: <4FAB1EE3.5060007@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1257) Cc: "precis@ietf.org" Subject: Re: [precis] codepoint table X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 04:35:09 -0000 On 10 maj 2012, at 03:50, Peter Saint-Andre wrote: > I'm almost finished with the codepoint table. Basically my process has > been to copy over the codepoint table from RFC 5892 and update it in > accordance with the new PRECIS rules and Unicode 6.1 UnicodeData.txt. > While completing this work, I realize it would have been very helpful > for the IDNA table to contain a column describing the reason for each > assignment (e.g., codepoints 1100..115F are DISALLOWED in IDNA2008 > because they trigger the OldHangulJamo (I) rule). This is more work = for > the person making the codepoint table (c'est moi), but it provides > better traceability, so I am thinking about adding this information to > the PRECIS codepoint table. Let me know if you have concerns. :) Note that the table in 5892 is non-normative. Similar derived lists = exists for the latest version of Unicode at IANA. One should really not = "copy a table", but instead use the algorithm specified. If you do, then = you would directly see what the reason is for the derived property = value. You can also have a look at http://stupid.domain.name/idna Patrik From stpeter@stpeter.im Thu May 10 10:44:21 2012 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5225021F86AB for ; Thu, 10 May 2012 10:44:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.406 X-Spam-Level: X-Spam-Status: No, score=-102.406 tagged_above=-999 required=5 tests=[AWL=-0.107, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LE9aqCoN4D0O for ; Thu, 10 May 2012 10:44:20 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id B530221F8683 for ; Thu, 10 May 2012 10:44:20 -0700 (PDT) Received: from [192.168.0.9] (unknown [216.17.175.160]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A135B40058; Thu, 10 May 2012 11:59:44 -0600 (MDT) Message-ID: <4FABFE74.8020801@stpeter.im> Date: Thu, 10 May 2012 11:44:20 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: =?UTF-8?B?UGF0cmlrIEbDpGx0c3Ryw7Zt?= References: <4FAB1EE3.5060007@stpeter.im> <24F7F85B-1434-415E-962D-F9FC52879BAD@frobbit.se> In-Reply-To: <24F7F85B-1434-415E-962D-F9FC52879BAD@frobbit.se> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "precis@ietf.org" Subject: Re: [precis] codepoint table X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 17:44:21 -0000 On 5/9/12 10:35 PM, Patrik Fältström wrote: > > On 10 maj 2012, at 03:50, Peter Saint-Andre wrote: > >> I'm almost finished with the codepoint table. Basically my process >> has been to copy over the codepoint table from RFC 5892 and update >> it in accordance with the new PRECIS rules and Unicode 6.1 >> UnicodeData.txt. While completing this work, I realize it would >> have been very helpful for the IDNA table to contain a column >> describing the reason for each assignment (e.g., codepoints >> 1100..115F are DISALLOWED in IDNA2008 because they trigger the >> OldHangulJamo (I) rule). This is more work for the person making >> the codepoint table (c'est moi), but it provides better >> traceability, so I am thinking about adding this information to the >> PRECIS codepoint table. Let me know if you have concerns. :) > > Note that the table in 5892 is non-normative. Similar derived lists > exists for the latest version of Unicode at IANA. One should really > not "copy a table", but instead use the algorithm specified. I copied it as a way to get started, rather than starting from scratch. > If you > do, then you would directly see what the reason is for the derived > property value. > > You can also have a look at http://stupid.domain.name/idna Thanks! Peter -- Peter Saint-Andre https://stpeter.im/ From internet-drafts@ietf.org Thu May 10 16:04:32 2012 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4515511E8085; Thu, 10 May 2012 16:04:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.426 X-Spam-Level: X-Spam-Status: No, score=-102.426 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OLUMwKbrKmW6; Thu, 10 May 2012 16:04:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F50A21F85A2; Thu, 10 May 2012 16:04:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120510230431.5573.99348.idtracker@ietfa.amsl.com> Date: Thu, 10 May 2012 16:04:31 -0700 Cc: precis@ietf.org Subject: [precis] I-D Action: draft-ietf-precis-framework-03.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 23:04:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Preparation and Comparison of Interna= tionalized Strings Working Group of the IETF. Title : PRECIS Framework: Preparation and Comparison of Internat= ionalized Strings in Application Protocols Author(s) : Peter Saint-Andre Marc Blanchet Filename : draft-ietf-precis-framework-03.txt Pages : 63 Date : 2012-05-10 Application protocols using Unicode code points in protocol strings need to prepare such strings in order to perform comparison operations (e.g., for purposes of authentication or authorization). This document defines a framework enabling application protocols to handle various classes of strings in a way that depends on the properties of Unicode code points and that is agile with respect to versions of Unicode; as a result, this framework provides a more sustainable approach to the handling of internationalized strings than the previous framework, known as Stringprep (RFC 3454). A specification that reuses this framework can either directly use the base string classes or subclass the base string classes as needed. This framework takes an approach similar to the revised internationalized domain names in applications (IDNA) technology (RFC 5890, RFC 5891, RFC 5892, RFC 5893, RFC 5894) and thus adheres to the high-level design goals described in RFC 4690, albeit for application technologies other than the Domain Name System (DNS). This document obsoletes RFC 3454. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-precis-framework-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-precis-framework-03.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-precis-framework/ From stpeter@stpeter.im Thu May 10 16:07:31 2012 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0B9821F84FE for ; Thu, 10 May 2012 16:07:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.554 X-Spam-Level: X-Spam-Status: No, score=-102.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id We2pD7L74eiN for ; Thu, 10 May 2012 16:07:31 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 66F6421F84E6 for ; Thu, 10 May 2012 16:07:31 -0700 (PDT) Received: from [192.168.0.9] (unknown [216.17.175.160]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 5946E40058 for ; Thu, 10 May 2012 17:22:56 -0600 (MDT) Message-ID: <4FAC4A34.6000603@stpeter.im> Date: Thu, 10 May 2012 17:07:32 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "precis@ietf.org" X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [precis] framework -03 X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 23:07:32 -0000 I just submitted version -03 of the framework, reflecting discussion before and during IETF 83. The codepoint table is a "first pass" and needs a lot more attention (double-checking many of the code points etc.), which I plan to do over the next few weeks. Feedback is welcome! Peter -- Peter Saint-Andre https://stpeter.im/ From alexey.melnikov@isode.com Wed May 16 10:46:22 2012 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F41C21F85B7 for ; Wed, 16 May 2012 10:46:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.691 X-Spam-Level: X-Spam-Status: No, score=-102.691 tagged_above=-999 required=5 tests=[AWL=-0.092, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P2L8unCt0-+j for ; Wed, 16 May 2012 10:46:21 -0700 (PDT) Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id EE93B21F854C for ; Wed, 16 May 2012 10:46:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1337190379; d=isode.com; s=selector; i=@isode.com; bh=VX4kEOibJawq/vJo5V34+lCHx7acKaN0XWFpGZUiBOg=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=W7P+nVdo9UZOCfFuMvEI2DdcPl95ZsZeG4fgM55PRyEx2uWb/WIwXo/B+9rBXBQ2hOYKQo bdDJ06K1h48C3gW4GtOaRCyAvE4eECCJtWgijU6jCGzfhPOuyGUvaKsH27TfHOLViLQQbR aMPx10FsKlJP2B7q/OoW8ZJ5IwPw9jg=; Received: from [172.16.11.4] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 16 May 2012 18:46:19 +0100 Message-ID: <4FB3E843.3080702@isode.com> Date: Wed, 16 May 2012 18:47:47 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 To: precis@ietf.org References: <20120509102419.4e8188d1.yoshiro.yoneya@jprs.co.jp> <4FA9F473.2010802@stpeter.im> In-Reply-To: <4FA9F473.2010802@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [precis] WGLC: draft-ietf-precis-problem-statement-05.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 17:46:22 -0000 I've reviewed the document and didn't find anything beyond what was already reported by Peter and Simon. I think the document is in a good shape.