From stpeter@stpeter.im Sun Jul 3 19:34:18 2011 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 5FB5F1F0C53 for ; Sun, 3 Jul 2011 19:34:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.449 X-Spam-Level: X-Spam-Status: No, score=-104.449 tagged_above=-999 required=5 tests=[AWL=-1.850, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SEEF53-UQUrl for ; Sun, 3 Jul 2011 19:34:17 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id DFF1E1F0C4D for ; Sun, 3 Jul 2011 19:34:17 -0700 (PDT) Received: from squire.local (unknown [216.17.179.111]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 07E7240E24 for ; Sun, 3 Jul 2011 20:34:28 -0600 (MDT) Message-ID: <4E1126A8.5030707@stpeter.im> Date: Sun, 03 Jul 2011 20:34:16 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: precis@ietf.org X-Enigmail-Version: 1.1.1 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [precis] Fwd: I-D Action: draft-iab-identifier-comparison-00.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2011 02:34:18 -0000 Of interest... -------- Original Message -------- Subject: I-D Action: draft-iab-identifier-comparison-00.txt Date: Sat, 02 Jul 2011 11:38:34 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Issues in Identifier Comparison for Security Purposes Author(s) : Dave Thaler Filename : draft-iab-identifier-comparison-00.txt Pages : 19 Date : 2011-07-02 Identifiers such as hostnames, URIs/IRIs, and email addresses are often used in security contexts to identify security principals and resources. In such contexts, an identifier supplied via some protocol is often compared against some policy to make security decisions such as whether the principal may access the resource, what level of authentication or encryption is required, etc. If the parties involved in a security decision use different algorithms to compare identifiers, then failure scenarios ranging from denial of service to elevation of privilege can result. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-iab-identifier-comparison-00.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-iab-identifier-comparison-00.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From yoshiro.yoneya@jprs.co.jp Mon Jul 4 07:56:16 2011 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 97B3821F862B for ; Mon, 4 Jul 2011 07:56:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.79 X-Spam-Level: X-Spam-Status: No, score=-98.79 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kydJoz4XSGdN for ; Mon, 4 Jul 2011 07:56:16 -0700 (PDT) Received: from send12.jprs.co.jp (send12.jprs.co.jp [IPv6:2001:df0:8:6::72]) by ietfa.amsl.com (Postfix) with ESMTP id 66CEB21F8622 for ; Mon, 4 Jul 2011 07:56:15 -0700 (PDT) Received: from sendsms12.jprs.co.jp (sendsms12.jprs.co.jp [202.11.17.114]) by send12.jprs.co.jp (8.13.8+Sun/8.13.8) with ESMTP id p64EuD2J012075 for ; Mon, 4 Jul 2011 23:56:13 +0900 (JST) Received: from sendsms12.jprs.co.jp (unknown [127.0.0.1]) by sendsms12.jprs.co.jp (Symantec Mail Security) with ESMTP id 3D8C83452 for ; Mon, 4 Jul 2011 23:56:13 +0900 (JST) X-AuditID: ca0b1172-00000005000010a3-c1-4e11d48a60f1 Date: Mon, 04 Jul 2011 23:56:10 +0900 (JST) Message-Id: <20110704.235610.52195060.yoshiro.yoneya@jprs.co.jp> To: precis@ietf.org From: Yoshiro YONEYA Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: [precis] [remind] Precis interim meeting: July 6th 13:00 UTC 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, 04 Jul 2011 14:56:16 -0000 This is reminder and instruction of precis WG interim meeting. As announced before, we'll have interim meeting on July 6th, 13:00 UTC, which is: - July 6th, 09:00 Montreal - July 6th, 07:00 Denver - July 6th, 06:00 Seattle - July 6th, 22:00 Tokyo Proposed agenda items are problem-statement and framework document. For the framework document, co-chairs are planning to adopt it as WG document according to WG charter. If you have any objections, please explain them and discuss in the interim meeting. The interim meeting is scheduled as WebEx meeting. Please follow the following instructions to join the meeting. ====================================================================== Topic: PRECIS Date: Wednesday, July 6, 2011 Time: 6:00 am, Pacific Daylight Time (San Francisco, GMT-07:00) Meeting Number: 963 409 853 Meeting Password: (This meeting does not require a password.) ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://workgreen.webex.com/workgreen/j.php?ED=154184662&UID=1215987537&RT=MiM0 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: (This meeting does not require a password.) 4. Click "Join". To view in other time zones or languages, please click the link: https://workgreen.webex.com/workgreen/j.php?ED=154184662&UID=1215987537&ORT=MiM0 ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- To receive a call back, provide your phone number when you join the meeting, or call the number below and enter the access code. Call-in toll number (US/Canada): 1-408-792-6300 Global call-in numbers: https://workgreen.webex.com/workgreen/globalcallin.php?serviceType=MC&ED=154184662&tollFree=0 Access code:963 409 853 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://workgreen.webex.com/workgreen/mc 2. On the left navigation bar, click "Support". ====================================================================== See you soon! Marc&Yoneya, co-chairs. -- Yoshiro YONEYA From stpeter@stpeter.im Wed Jul 6 20:44:27 2011 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 C910D21F8A3C for ; Wed, 6 Jul 2011 20:44:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.169 X-Spam-Level: X-Spam-Status: No, score=-103.169 tagged_above=-999 required=5 tests=[AWL=-0.570, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01MGhj-hI3uJ for ; Wed, 6 Jul 2011 20:44:27 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 276F221F8A36 for ; Wed, 6 Jul 2011 20:44:27 -0700 (PDT) Received: from squire.local (unknown [216.17.179.111]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 5805140F84 for ; Wed, 6 Jul 2011 21:44:32 -0600 (MDT) Message-ID: <4E152B89.3070006@stpeter.im> Date: Wed, 06 Jul 2011 21:44:09 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: precis@ietf.org X-Enigmail-Version: 1.1.1 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [precis] buckets 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, 07 Jul 2011 03:44:27 -0000 In draft-iab-identifier-comparison-00, Dave Thaler describes the same "buckets" from draft-ietf-precis-problem-statement. It would be good to have common terminology here. Dave's terms "Absolute", "Definite", and "Indefinite" seem fine to me (and preferable to "Type 1", "Type 2", and "Type 3" currently in draft-ietf-precis-problem-statement). The PRECIS draft also says: A subclass of case (3) is one in which, within some constrained population, the comparison rules are clear even though such rules are not universally applicable. So, for instance, users of US-ASCII may all agree on a comparison function, but the set of US-ASCII users and Turkish users may not all agree about the same comparison function. For the purposes of the present work, it is not plain whether this subclass case is relevant, so categorization will include it. It's not clear to me if we need this "Type 3a" bucket. Dave's draft says: o Indefinite: identifiers that have no single comparison algorithm on which all parties agree. For example, human names are in this class. Everyone might want the comparison to be tailored for their locale, for some definition of locale. In some cases, there may be limited subsets of parties that might be able to agree (e.g., US-ASCII users might all agree on a comparison algorithm whereas US-ASCII and Turkish users may not), but identifiers often tend to leak out of such limited environments. Here again, a common understanding would be beneficial. My first impression is that we can probably do away with the "Type 3a" bucket, although we might want to look at different examples of such "subsets of parties" to see whether the comparison algorithms they use really will leak out in all cases. Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Mon Jul 11 15:36:02 2011 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 940A211E834D for ; Mon, 11 Jul 2011 15:36:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.98 X-Spam-Level: X-Spam-Status: No, score=-102.98 tagged_above=-999 required=5 tests=[AWL=-0.381, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p3XxLLkr3ouc for ; Mon, 11 Jul 2011 15:36:02 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id E476111E834C for ; Mon, 11 Jul 2011 15:36:01 -0700 (PDT) Received: from squire.local (unknown [216.17.179.111]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 3FB8340FFF for ; Mon, 11 Jul 2011 16:36:20 -0600 (MDT) Message-ID: <4E1B7AD0.2060808@stpeter.im> Date: Mon, 11 Jul 2011 16:36:00 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: precis@ietf.org X-Enigmail-Version: 1.1.1 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [precis] Fwd: I-D Action: draft-blanchet-precis-framework-02.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 22:36:02 -0000 FYI, Marc and I have updated the framework spec. No really major changes here, but we did close a few open issues, change some terminology, and add to the security considerations. Peter -------- Original Message -------- Subject: I-D Action: draft-blanchet-precis-framework-02.txt Date: Mon, 11 Jul 2011 15:19:50 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : PRECIS Framework: Handling Internationalized Strings in Protocols Author(s) : Marc Blanchet Peter Saint-Andre Filename : draft-blanchet-precis-framework-02.txt Pages : 26 Date : 2011-07-11 Application protocols that make use of 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). In general, this problem has been labeled the "preparation and comparison of internationalized strings" or "PRECIS". This document defines a framework that enables application protocols to prepare various classes of strings in a way that depends on the properties of Unicode code points. Because this framework does not depend on large tables of Unicode code points as in stringprep (RFC 3454), it is more agile with regard to changes in the underlying Unicode database and thus provides improved flexibility to application protocols. A specification that uses this framework either can directly use the base string classes defined in this document or can subclass the base string classes as needed. This framework uses an approach similar to that of 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 PRECIS technologies. This document obsoletes RFC 3454. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-blanchet-precis-framework-02.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-blanchet-precis-framework-02.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From internet-drafts@ietf.org Mon Jul 11 16:25:05 2011 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 58EB711E83B0; Mon, 11 Jul 2011 16:25:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h0LxE0mEBZdQ; Mon, 11 Jul 2011 16:25:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA52411E838D; Mon, 11 Jul 2011 16:25:04 -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: 3.55 Message-ID: <20110711232504.17969.21565.idtracker@ietfa.amsl.com> Date: Mon, 11 Jul 2011 16:25:04 -0700 Cc: precis@ietf.org Subject: [precis] I-D Action: draft-ietf-precis-problem-statement-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: Mon, 11 Jul 2011 23:25:05 -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 : Stringprep Revision Problem Statement Author(s) : Marc Blanchet Andrew Sullivan Filename : draft-ietf-precis-problem-statement-03.txt Pages : 18 Date : 2011-07-11 Using Unicode codepoints in protocol strings that expect comparison with other strings requires preparation of the string that contains the Unicode codepoints. Internationalizing Domain Names in Applications (IDNA2003) defined and used Stringprep and Nameprep. Other protocols subsequently defined Stringprep profiles. A new approach different from Stringprep and Nameprep is used for a revision of IDNA2003 (called IDNA2008). Other Stringprep profiles need to be similarly updated or a replacement of Stringprep needs to be designed. This document outlines the issues to be faced by those designing a Stringprep replacement. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-precis-problem-statement-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-problem-statement-03.t= xt From ajs@crankycanuck.ca Mon Jul 11 16:34:23 2011 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 AAE4B11E83CB for ; Mon, 11 Jul 2011 16:34:23 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3z+n2UhEY-uS for ; Mon, 11 Jul 2011 16:34:23 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 2327F11E83CA for ; Mon, 11 Jul 2011 16:34:23 -0700 (PDT) Received: from shinkuro.com (unknown [12.176.20.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 2844A1ECB41D for ; Mon, 11 Jul 2011 23:34:21 +0000 (UTC) Date: Mon, 11 Jul 2011 19:34:20 -0400 From: Andrew Sullivan To: precis@ietf.org Message-ID: <20110711233420.GB6886@shinkuro.com> References: <20110711232504.17969.21565.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110711232504.17969.21565.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [precis] I-D Action: draft-ietf-precis-problem-statement-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: Mon, 11 Jul 2011 23:34:23 -0000 Dear colleagues, On Mon, Jul 11, 2011 at 04:25:04PM -0700, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Preparation and Comparison of Internationalized Strings Working Group of the IETF. > > Title : Stringprep Revision Problem Statement > Author(s) : Marc Blanchet > Andrew Sullivan > Filename : draft-ietf-precis-problem-statement-03.txt > Pages : 18 > Date : 2011-07-11 Marc and I submitted an update to the problem statement. There's not a great deal of progress, I admit to my chagrin, but there is some. Notably, - the "bucket" terminology has bene put into line with the latest IAB draft on the topic - we incorporated a categorization heavily cribbed from Peter Saint Andre's "Nameythings" &c. presentation and draft - a table in an appendix is started to summarize the reviews along the above lines. I'd be especially interested in whether people think that table is worth anything, before I complete it. I'm of two minds. Thanks and best regards, A -- Andrew Sullivan ajs@crankycanuck.ca From dthaler@microsoft.com Mon Jul 11 17:14:27 2011 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 370DC21F90A6 for ; Mon, 11 Jul 2011 17:14:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.574 X-Spam-Level: X-Spam-Status: No, score=-110.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cT-t-ZKKWgXg for ; Mon, 11 Jul 2011 17:14:26 -0700 (PDT) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 87F9721F90A5 for ; Mon, 11 Jul 2011 17:14:26 -0700 (PDT) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 11 Jul 2011 17:14:26 -0700 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) with Microsoft SMTP Server (TLS) id 14.1.323.2; Mon, 11 Jul 2011 17:14:26 -0700 Received: from TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.59]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.01.0289.008; Mon, 11 Jul 2011 17:14:25 -0700 From: Dave Thaler To: Andrew Sullivan , Alexey Melnikov Thread-Topic: [precis] I-D Action: draft-ietf-precis-problem-statement-03.txt Thread-Index: AQHMQCHtIjbY3Ui59U6XkYP32ApnCJToOzIA//+TQ3A= Date: Tue, 12 Jul 2011 00:14:24 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B15F15D@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> References: <20110711232504.17969.21565.idtracker@ietfa.amsl.com> <20110711233420.GB6886@shinkuro.com> In-Reply-To: <20110711233420.GB6886@shinkuro.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "precis@ietf.org" Subject: Re: [precis] I-D Action: draft-ietf-precis-problem-statement-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: Tue, 12 Jul 2011 00:14:27 -0000 Andrew Sullivan asked: > I'd be especially interested in whether people think that table is worth > anything, before I complete it. I'm of two minds. I'd say yes. To its credit, it made me go look at one of the reviews (Alexey's review of= =20 RFC4314 at http://www.ietf.org/mail-archive/web/precis/current/msg00086.htm= l) for more info. I'm not that familiar with IMAP or SASLprep so I am confus= ed about one thing and hope someone can explain it in simple terms for me :) The review says: > Most likely case sensitive. Exact requirements on case-sensitivity/case-p= reservation > depend on a specific implementation, e.g. an implementation might treat a= ll user=20 > identifiers as case insensitive (or case insensitive for US-ASCII subset = only). But RFC 4013 says: > This profile is not intended for use in > preparing identity strings that are not simple user names (e.g., > email addresses, domain names, distinguished names), or where > identity or password strings that are not character data, or require > different handling (e.g., case folding). The table Andrew added has "a,d" (but not "i"). That would be correct if a= ll implementations agreed on the case sensitivity rules. And RFC 4013 says i= t's not appropriate for things that aren't case sensitive. So I'm confused about the part of the review saying: "Exact requirements on case-sensitivity/case-preservation depend on a specific implementation, e.g. an implementation might treat all= user=20 identifiers as case insensitive (or case insensitive for US-ASCII subset on= ly)." Can someone elaborate on this? Thanks, -Dave From marc.blanchet@viagenie.ca Mon Jul 11 17:44:43 2011 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 E7B3411E83F7 for ; Mon, 11 Jul 2011 17:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F4Uj8q9JEaEQ for ; Mon, 11 Jul 2011 17:44:43 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id EF5F311E8158 for ; Mon, 11 Jul 2011 17:44:42 -0700 (PDT) Received: from mbl.local (unknown [IPv6:2607:fa48:6e3e:a070:5ab0:35ff:fe6a:294a]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 13F1D21CB6 for ; Mon, 11 Jul 2011 20:44:42 -0400 (EDT) Message-ID: <4E1B98F9.9030305@viagenie.ca> Date: Mon, 11 Jul 2011 20:44:41 -0400 From: Marc Blanchet User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; fr; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: precis@ietf.org References: <4E1B7AD0.2060808@stpeter.im> In-Reply-To: <4E1B7AD0.2060808@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [precis] Fwd: I-D Action: draft-blanchet-precis-framework-02.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 00:44:44 -0000 s/Marc and I/I/ Marc. Le 11-07-11 18:36, Peter Saint-Andre a écrit : > FYI, Marc and I have updated the framework spec. No really major changes > here, but we did close a few open issues, change some terminology, and > add to the security considerations. > > Peter > > -------- Original Message -------- > Subject: I-D Action: draft-blanchet-precis-framework-02.txt > Date: Mon, 11 Jul 2011 15:19:50 -0700 > From: internet-drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : PRECIS Framework: Handling Internationalized Strings > in Protocols > Author(s) : Marc Blanchet > Peter Saint-Andre > Filename : draft-blanchet-precis-framework-02.txt > Pages : 26 > Date : 2011-07-11 > > Application protocols that make use of 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). In general, this problem has been labeled the > "preparation and comparison of internationalized strings" or > "PRECIS". This document defines a framework that enables > application > protocols to prepare various classes of strings in a way that depends > on the properties of Unicode code points. Because this framework > does not depend on large tables of Unicode code points as in > stringprep (RFC 3454), it is more agile with regard to changes in the > underlying Unicode database and thus provides improved flexibility to > application protocols. A specification that uses this framework > either can directly use the base string classes defined in this > document or can subclass the base string classes as needed. This > framework uses an approach similar to that of 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 PRECIS > technologies. This document obsoletes RFC 3454. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-blanchet-precis-framework-02.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-blanchet-precis-framework-02.txt > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > _______________________________________________ > precis mailing list > precis@ietf.org > https://www.ietf.org/mailman/listinfo/precis -- ========= IETF81 Quebec city: http://ietf81.ca IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca DTN Implementation: http://postellation.viagenie.ca NAT64-DNS64 Opensource: http://ecdysis.viagenie.ca Space Assigned Number Authority: http://sanaregistry.org From yoshiro.yoneya@jprs.co.jp Tue Jul 12 22:43:03 2011 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 E415021F8B3A for ; Tue, 12 Jul 2011 22:43:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.44 X-Spam-Level: X-Spam-Status: No, score=-99.44 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8vNEja3CtjXl for ; Tue, 12 Jul 2011 22:43:03 -0700 (PDT) Received: from send12.jprs.co.jp (send12.jprs.co.jp [IPv6:2001:df0:8:6::72]) by ietfa.amsl.com (Postfix) with ESMTP id 0947221F8B38 for ; Tue, 12 Jul 2011 22:43:01 -0700 (PDT) Received: from sendsms12.jprs.co.jp (sendsms12.jprs.co.jp [202.11.17.114]) by send12.jprs.co.jp (8.13.8+Sun/8.13.8) with ESMTP id p6D5gv9r022401 for ; Wed, 13 Jul 2011 14:42:57 +0900 (JST) Received: from sendsms12.jprs.co.jp (unknown [127.0.0.1]) by sendsms12.jprs.co.jp (Symantec Mail Security) with ESMTP id 83B2B34C8 for ; Wed, 13 Jul 2011 14:42:57 +0900 (JST) X-AuditID: ca0b1172-00000006000010a3-ef-4e1d30613771 Received: from NOTE550 (off-cpu04.tyo.jprs.co.jp [172.18.4.14]) by sendsms12.jprs.co.jp (Symantec Mail Security) with SMTP id 2B44134C7 for ; Wed, 13 Jul 2011 14:42:57 +0900 (JST) Date: Wed, 13 Jul 2011 14:42:54 +0900 From: Yoshiro YONEYA To: precis@ietf.org Message-Id: <20110713144254.9fa0f03c.yoshiro.yoneya@jprs.co.jp> X-Mailer: Sylpheed 3.1.1 (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: AAAAAA== Subject: [precis] IETF81 Quebec draft agenda X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 05:43:04 -0000 Dear all, Following is draft agenda for IETF 81 Quebec City. Please send comments/additions/changes to the chairs. 1. Administrativia 2. Problem-statement 3. Framework 4. Next steps Marc & Yoneya, co-chairs -- Yoshiro YONEYA From stpeter@stpeter.im Fri Jul 15 09:21:30 2011 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 0C2C721F8AD9 for ; Fri, 15 Jul 2011 09:21:30 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P-33J7T+dqot for ; Fri, 15 Jul 2011 09:21:29 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 5E16921F8AD3 for ; Fri, 15 Jul 2011 09:21:29 -0700 (PDT) Received: from dhcp-64-101-72-201.cisco.com (unknown [64.101.72.201]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D5D7B40327 for ; Fri, 15 Jul 2011 10:21:57 -0600 (MDT) Message-ID: <4E206907.20407@stpeter.im> Date: Fri, 15 Jul 2011 10:21:27 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: precis@ietf.org References: <20110711232504.17969.21565.idtracker@ietfa.amsl.com> <20110711233420.GB6886@shinkuro.com> In-Reply-To: <20110711233420.GB6886@shinkuro.com> X-Enigmail-Version: 1.2 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [precis] I-D Action: draft-ietf-precis-problem-statement-03.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 16:21:30 -0000 On 7/11/11 5:34 PM, Andrew Sullivan wrote: > Dear colleagues, > > On Mon, Jul 11, 2011 at 04:25:04PM -0700, internet-drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Preparation and Comparison of Internationalized Strings Working Group of the IETF. >> >> Title : Stringprep Revision Problem Statement >> Author(s) : Marc Blanchet >> Andrew Sullivan >> Filename : draft-ietf-precis-problem-statement-03.txt >> Pages : 18 >> Date : 2011-07-11 > > Marc and I submitted an update to the problem statement. There's not > a great deal of progress, I admit to my chagrin, but there is some. Notably, > > - the "bucket" terminology has bene put into line with the latest > IAB draft on the topic Super. > - we incorporated a categorization heavily cribbed from Peter > Saint Andre's "Nameythings" &c. presentation and draft BTW in draft-precis-framework-02 I changed the terminology because my co-author thought that *thing was a bit too informal. :) > - a table in an appendix is started to summarize the reviews along > the above lines. Excellent. I'll review that in more detail today. > I'd be especially interested in whether people think that table is > worth anything, before I complete it. I'm of two minds. I do think it's helpful to have much of that data available at a glance. Peter -- Peter Saint-Andre https://stpeter.im/ From alexey.melnikov@isode.com Sun Jul 17 11:33:11 2011 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 CC70121F8565 for ; Sun, 17 Jul 2011 11:33:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.483 X-Spam-Level: X-Spam-Status: No, score=-102.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8W1tnlGbC5UY for ; Sun, 17 Jul 2011 11:33:11 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 959B321F8562 for ; Sun, 17 Jul 2011 11:33:10 -0700 (PDT) Received: from [188.29.221.60] (188.29.221.60.threembb.co.uk [188.29.221.60]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sun, 17 Jul 2011 19:33:08 +0100 Message-ID: <4E232ACB.7070105@isode.com> Date: Sun, 17 Jul 2011 19:32:43 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Dave Thaler References: <20110711232504.17969.21565.idtracker@ietfa.amsl.com> <20110711233420.GB6886@shinkuro.com> <9B57C850BB53634CACEC56EF4853FF653B15F15D@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B15F15D@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Andrew Sullivan , "precis@ietf.org" Subject: Re: [precis] I-D Action: draft-ietf-precis-problem-statement-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: Sun, 17 Jul 2011 18:33:11 -0000 Hi Dave, Dave Thaler wrote: >Andrew Sullivan asked: > >>I'd be especially interested in whether people think that table is worth >>anything, before I complete it. I'm of two minds. >> >> > >I'd say yes. > >To its credit, it made me go look at one of the reviews (Alexey's review of >RFC4314 at http://www.ietf.org/mail-archive/web/precis/current/msg00086.html) >for more info. I'm not that familiar with IMAP or SASLprep so I am confused about >one thing and hope someone can explain it in simple terms for me :) > >The review says: > > >>Most likely case sensitive. Exact requirements on case-sensitivity/case-preservation >>depend on a specific implementation, e.g. an implementation might treat all user >>identifiers as case insensitive (or case insensitive for US-ASCII subset only). >> >> > >But RFC 4013 says: > > >>This profile is not intended for use in >>preparing identity strings that are not simple user names (e.g., >>email addresses, domain names, distinguished names), or where >>identity or password strings that are not character data, or require >>different handling (e.g., case folding). >> I don't think there is necessarily a contradiction. Case folding can be applied as an extra step after RFC 4013 processing. >The table Andrew added has "a,d" (but not "i"). That would be correct if all >implementations agreed on the case sensitivity rules. And RFC 4013 says it's >not appropriate for things that aren't case sensitive. > >So I'm confused about the part of the review saying: >"Exact requirements on case-sensitivity/case-preservation >depend on a specific implementation, e.g. an implementation might treat all user >identifiers as case insensitive (or case insensitive for US-ASCII subset only)." > >Can someone elaborate on this? > > Ok, let me try to elaborate on my review and why I wrote what I wrote. I was talking specifically about IMAP/POP/SMTP usernames (passwords are another story). Many email servers support all of the three protocols and use the same identity format in all three. For a given email address the corresponding user identity is either the left hand side of the email address and/or the whole email address. (This isn't documented anywhere, but it is one of the things that all email implementors need to know.) The domain part (if included) is case-insensitive. SMTP (RFC 5321) says that the left hand side is case sensitive. In practice this restriction turned out to be quite problematic in real deployments (because humans just don't pay attention to case sometimes) and most of the systems I know of treat left hand sides as case sensitive. However until and unless an update to RFC 5321 declares that all left hand sides of email addresses are case insensitive, we can't say that left hand sides are always case insensitive, as some systems might rely on case sensitivity of left hand sides. Does this help? Best Regards, Alexey -- Internet Messaging Team Lead, JID: same as my email address twitter: aamelnikov From dthaler@microsoft.com Mon Jul 18 11:11:47 2011 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 D6DB821F8B2E for ; Mon, 18 Jul 2011 11:11:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.534 X-Spam-Level: X-Spam-Status: No, score=-110.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9WKOXaQ1Ilji for ; Mon, 18 Jul 2011 11:11:44 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 0DA5321F855B for ; Mon, 18 Jul 2011 11:11:44 -0700 (PDT) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 18 Jul 2011 11:11:40 -0700 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) with Microsoft SMTP Server (TLS) id 14.1.323.2; Mon, 18 Jul 2011 11:11:40 -0700 Received: from TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.59]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.01.0289.008; Mon, 18 Jul 2011 11:11:39 -0700 From: Dave Thaler To: Alexey Melnikov Thread-Topic: [precis] I-D Action: draft-ietf-precis-problem-statement-03.txt Thread-Index: AQHMQCHtIjbY3Ui59U6XkYP32ApnCJToOzIA//+TQ3CACYZ0gIABFu0Q Date: Mon, 18 Jul 2011 18:11:39 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B16C62A@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> References: <20110711232504.17969.21565.idtracker@ietfa.amsl.com> <20110711233420.GB6886@shinkuro.com> <9B57C850BB53634CACEC56EF4853FF653B15F15D@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <4E232ACB.7070105@isode.com> In-Reply-To: <4E232ACB.7070105@isode.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Andrew Sullivan , "precis@ietf.org" Subject: Re: [precis] I-D Action: draft-ietf-precis-problem-statement-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: Mon, 18 Jul 2011 18:11:48 -0000 Thanks for the elaboration. Doesn't that make 4314's use of identifiers qualify as Indefinite? (If so, Andrew's table should be updated.) -Dave -----Original Message----- From: Alexey Melnikov [mailto:alexey.melnikov@isode.com]=20 Sent: Sunday, July 17, 2011 11:33 AM To: Dave Thaler Cc: Andrew Sullivan; precis@ietf.org Subject: Re: [precis] I-D Action: draft-ietf-precis-problem-statement-03.tx= t Hi Dave, Dave Thaler wrote: >Andrew Sullivan asked: =20 > >>I'd be especially interested in whether people think that table is=20 >>worth anything, before I complete it. I'm of two minds. >> =20 >> > >I'd say yes. > >To its credit, it made me go look at one of the reviews (Alexey's=20 >review of >RFC4314 at http://www.ietf.org/mail-archive/web/precis/current/msg00086.ht= ml) >for more info. I'm not that familiar with IMAP or SASLprep so I am confu= sed about >one thing and hope someone can explain it in simple terms for me :) > >The review says: > =20 > >>Most likely case sensitive. Exact requirements on=20 >>case-sensitivity/case-preservation >>depend on a specific implementation, e.g. an implementation might=20 >>treat all user identifiers as case insensitive (or case insensitive for U= S-ASCII subset only). >> =20 >> > >But RFC 4013 says: > =20 > >>This profile is not intended for use in preparing identity strings=20 >>that are not simple user names (e.g., email addresses, domain names,=20 >>distinguished names), or where identity or password strings that are=20 >>not character data, or require different handling (e.g., case=20 >>folding). >> I don't think there is necessarily a contradiction. Case folding can be app= lied as an extra step after RFC 4013 processing. >The table Andrew added has "a,d" (but not "i"). That would be correct if = all >implementations agreed on the case sensitivity rules. And RFC 4013 says = it's >not appropriate for things that aren't case sensitive. > >So I'm confused about the part of the review saying: >"Exact requirements on case-sensitivity/case-preservation >depend on a specific implementation, e.g. an implementation might treat=20 >all user identifiers as case insensitive (or case insensitive for US-ASCII= subset only)." > >Can someone elaborate on this? > =20 > Ok, let me try to elaborate on my review and why I wrote what I wrote. I wa= s talking specifically about IMAP/POP/SMTP usernames (passwords are another= story). Many email servers support all of the three protocols and use the = same identity format in all three. For a given email address the correspond= ing user identity is either the left hand side of the email address and/or = the whole email address. (This isn't documented anywhere, but it is one of = the things that all email implementors need to know.) The domain part (if i= ncluded) is case-insensitive. SMTP (RFC 5321) says that the left hand side is case sensitive. In practice this rest= riction turned out to be quite problematic in real deployments (because hum= ans just don't pay attention to case sometimes) and most of the systems I k= now of treat left hand sides as case sensitive. However until and unless an= update to RFC 5321 declares that all left hand sides of email addresses ar= e case insensitive, we can't say that left hand sides are always case insen= sitive, as some systems might rely on case sensitivity of left hand sides. Does this help? Best Regards, Alexey -- Internet Messaging Team Lead, JID: same as my email address twitter: aamelnikov =20 From stpeter@stpeter.im Tue Jul 19 11:50:53 2011 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 A11D211E8082 for ; Tue, 19 Jul 2011 11:50:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.747 X-Spam-Level: X-Spam-Status: No, score=-102.747 tagged_above=-999 required=5 tests=[AWL=-0.148, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oNfl237t7WAF for ; Tue, 19 Jul 2011 11:50:49 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 77BB311E807A for ; Tue, 19 Jul 2011 11:50:48 -0700 (PDT) Received: from dhcp-64-101-72-201.cisco.com (unknown [64.101.72.201]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id CB8464005A for ; Tue, 19 Jul 2011 12:51:27 -0600 (MDT) Message-ID: <4E25D206.6030503@stpeter.im> Date: Tue, 19 Jul 2011 12:50:46 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: precis@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [precis] Fwd: [apps-discuss] i18n intro, Sunday 14:00-16:00 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, 19 Jul 2011 18:50:53 -0000 FYI. -------- Original Message -------- Subject: [apps-discuss] i18n intro, Sunday 14:00-16:00 Date: Tue, 19 Jul 2011 12:48:39 -0600 From: Peter Saint-Andre To: apps-discuss@ietf.org You might have noticed a curious item on the agenda at 14:00 on Sunday: "Apps Area Preparatory Meeting for Internationalization Working Groups". At that time, I will present an introduction to internationalization, assisted by Pete Resnick (who will correct me where I go wrong). The intent of this session is to help apps-area folks learn more about internationalization, especially in preparation for the PRECIS WG meeting on Thursday. The room we've been assigned (2103) holds up to 60 people so we should have plenty of space, and there is no need to sign up if you want to attend. If this session goes well, Pete and I might offer a more general tutorial at a future IETF meeting. Consider Sunday's session a dry run. See you in Quebec City! Peter -- Peter Saint-Andre https://stpeter.im/ _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From stpeter@stpeter.im Tue Jul 19 18:25:12 2011 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 EFA5311E808B for ; Tue, 19 Jul 2011 18:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.932 X-Spam-Level: X-Spam-Status: No, score=-102.932 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GcYQqg27CXDQ for ; Tue, 19 Jul 2011 18:25:08 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 1957611E8098 for ; Tue, 19 Jul 2011 18:25:08 -0700 (PDT) Received: from squire.local (unknown [216.17.179.111]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9A2144005A for ; Tue, 19 Jul 2011 19:25:48 -0600 (MDT) Message-ID: <4E262E6A.8000503@stpeter.im> Date: Tue, 19 Jul 2011 19:24:58 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: precis@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [precis] draft slides for precis-framework 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, 20 Jul 2011 01:25:13 -0000 I've created somes slides about draft-blanchet-precis-framework for our discussions next week: http://www.saint-andre.com/ietf/ietf81-precis-framework.pdf Feedback is welcome. I'll provide a final version to the chairs before our session on Thursday. Peter -- Peter Saint-Andre https://stpeter.im/ From florob@babelmonkeys.de Wed Jul 20 05:18:34 2011 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 0F89821F874B for ; Wed, 20 Jul 2011 05:18:34 -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=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zUQoPKYC3EDL for ; Wed, 20 Jul 2011 05:18:28 -0700 (PDT) Received: from babelmonkeys.de (unknown [IPv6:2a01:4f8:140:9341:a2b3::ab]) by ietfa.amsl.com (Postfix) with ESMTP id 9801C21F86C4 for ; Wed, 20 Jul 2011 05:18:25 -0700 (PDT) Received: from [134.130.62.164] by v64231 with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1QjVjJ-0000q4-Kz for precis@ietf.org; Wed, 20 Jul 2011 14:18:21 +0200 Message-ID: <4E26C788.8080506@babelmonkeys.de> Date: Wed, 20 Jul 2011 14:18:16 +0200 From: Florian Zeitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110628 Thunderbird/5.0 MIME-Version: 1.0 To: precis@ietf.org References: <4E262E6A.8000503@stpeter.im> In-Reply-To: <4E262E6A.8000503@stpeter.im> X-Enigmail-Version: 1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [precis] draft slides for precis-framework 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, 20 Jul 2011 12:18:34 -0000 Am 20.07.2011 03:24, schrieb Peter Saint-Andre: > I've created somes slides about draft-blanchet-precis-framework for our > discussions next week: > > http://www.saint-andre.com/ietf/ietf81-precis-framework.pdf > > Feedback is welcome. I'll provide a final version to the chairs before > our session on Thursday. > > Peter > Feedback: Maybe I'm misguided, but I disagree with the "No more big tables" statement. You either need at least a code point to General_Category mapping and a way to tell whether a character is compatibility decomposable as input for the algorithmic classification, or a table containing the result of of the classification. Both seem relatively large to me. Also (and I'm going to repeat it until someone tells me why I'm wrong or acknowledges it), "Any character with a compatibility equivalent" is not what you mean, neither on the slides nor in the draft. It should be "Any compatibility decomposable character". -- Florian Zeitz From Joe.Hildebrand@webex.com Wed Jul 20 08:16:39 2011 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 7E4E021F876A for ; Wed, 20 Jul 2011 08:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.532 X-Spam-Level: X-Spam-Status: No, score=-104.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IuuKq4Iuz4d8 for ; Wed, 20 Jul 2011 08:16:39 -0700 (PDT) Received: from gw2.webex.com (gw2.webex.com [64.68.122.209]) by ietfa.amsl.com (Postfix) with SMTP id 1EF0B21F86DB for ; Wed, 20 Jul 2011 08:16:38 -0700 (PDT) Received: from SRV-EXSC03.webex.local ([192.168.252.197]) by gw2.webex.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 20 Jul 2011 08:16:37 -0700 Received: from 64.101.74.200 ([64.101.74.200]) by SRV-EXSC03.webex.local ([192.168.252.200]) with Microsoft Exchange Server HTTP-DAV ; Wed, 20 Jul 2011 15:16:37 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Wed, 20 Jul 2011 09:16:36 -0600 From: Joe Hildebrand To: Florian Zeitz , Message-ID: Thread-Topic: [precis] draft slides for precis-framework Thread-Index: AcxG8AP+BhP5LJfgD0GI4VFVEUhx7A== In-Reply-To: <4E26C788.8080506@babelmonkeys.de> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 20 Jul 2011 15:16:38.0063 (UTC) FILETIME=[05392BF0:01CC46F0] Subject: Re: [precis] draft slides for precis-framework 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, 20 Jul 2011 15:16:39 -0000 On 7/20/11 6:18 AM, "Florian Zeitz" wrote: > Maybe I'm misguided, but I disagree with the "No more big tables" > statement. You either need at least a code point to General_Category > mapping and a way to tell whether a character is compatibility > decomposable as input for the algorithmic classification, or a table > containing the result of of the classification. Both seem relatively > large to me. Perhaps "no more big tables maintained by the IETF" would resonate better? -- Joe Hildebrand From stpeter@stpeter.im Wed Jul 20 08:30:18 2011 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 2157521F85DD for ; Wed, 20 Jul 2011 08:30:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bYZtjrQ4NcW9 for ; Wed, 20 Jul 2011 08:30:17 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 9EDC221F85CD for ; Wed, 20 Jul 2011 08:30:17 -0700 (PDT) Received: from leavealone.cisco.com (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id C317B4005A; Wed, 20 Jul 2011 09:30:58 -0600 (MDT) Message-ID: <4E26F486.7040806@stpeter.im> Date: Wed, 20 Jul 2011 09:30:14 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Joe Hildebrand References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: precis@ietf.org Subject: Re: [precis] draft slides for precis-framework 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, 20 Jul 2011 15:30:18 -0000 On 7/20/11 9:16 AM, Joe Hildebrand wrote: > On 7/20/11 6:18 AM, "Florian Zeitz" wrote: > >> Maybe I'm misguided, but I disagree with the "No more big tables" >> statement. You either need at least a code point to General_Category >> mapping and a way to tell whether a character is compatibility >> decomposable as input for the algorithmic classification, or a table >> containing the result of of the classification. Both seem relatively >> large to me. > > Perhaps "no more big tables maintained by the IETF" would resonate better? Yes, that's more accurate. /psa From florob@babelmonkeys.de Wed Jul 20 08:31:46 2011 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 F1E8021F874F for ; Wed, 20 Jul 2011 08:31:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 51HhftWo+iaC for ; Wed, 20 Jul 2011 08:31:45 -0700 (PDT) Received: from babelmonkeys.de (unknown [IPv6:2a01:4f8:140:9341:a2b3::ab]) by ietfa.amsl.com (Postfix) with ESMTP id 5F4F321F874E for ; Wed, 20 Jul 2011 08:31:45 -0700 (PDT) Received: from [134.130.62.164] by v64231 with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1QjYkQ-0003Hq-4c; Wed, 20 Jul 2011 17:31:42 +0200 Message-ID: <4E26F4D9.9000405@babelmonkeys.de> Date: Wed, 20 Jul 2011 17:31:37 +0200 From: Florian Zeitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110628 Thunderbird/5.0 MIME-Version: 1.0 To: Joe Hildebrand References: In-Reply-To: X-Enigmail-Version: 1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: precis@ietf.org Subject: Re: [precis] draft slides for precis-framework 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, 20 Jul 2011 15:31:46 -0000 Am 20.07.2011 17:16, schrieb Joe Hildebrand: > On 7/20/11 6:18 AM, "Florian Zeitz" wrote: > >> Maybe I'm misguided, but I disagree with the "No more big tables" >> statement. You either need at least a code point to General_Category >> mapping and a way to tell whether a character is compatibility >> decomposable as input for the algorithmic classification, or a table >> containing the result of of the classification. Both seem relatively >> large to me. > > Perhaps "no more big tables maintained by the IETF" would resonate better? > Did the IETF itself ever maintain one? There is still the "PRECIS Derived Property Value Registry" mandated by section 9.1 to be maintained by the IANA, which (as I understand it) is basicaly the "table containing the result of the classification" that I mentioned. From stpeter@stpeter.im Wed Jul 20 09:27:17 2011 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 A806421F87C7 for ; Wed, 20 Jul 2011 09:27:17 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0CnT2X3cP3AP for ; Wed, 20 Jul 2011 09:27:13 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id AA68421F855B for ; Wed, 20 Jul 2011 09:27:13 -0700 (PDT) Received: from stpeter.im (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 5103A4005A; Wed, 20 Jul 2011 10:27:55 -0600 (MDT) Date: Wed, 20 Jul 2011 10:27:01 -0600 From: Peter Saint-Andre To: Florian Zeitz Message-ID: <20110720162701.GA97011@stpeter.im> References: <4E26F4D9.9000405@babelmonkeys.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E26F4D9.9000405@babelmonkeys.de> Jabber-ID: stpeter@jabber.org User-Agent: Mutt/1.5.21 (2010-09-15) Cc: precis@ietf.org Subject: Re: [precis] draft slides for precis-framework 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, 20 Jul 2011 16:27:17 -0000 On Wed, Jul 20, 2011 at 05:31:37PM +0200, Florian Zeitz wrote: > Am 20.07.2011 17:16, schrieb Joe Hildebrand: > > On 7/20/11 6:18 AM, "Florian Zeitz" wrote: > > > >> Maybe I'm misguided, but I disagree with the "No more big tables" > >> statement. You either need at least a code point to General_Category > >> mapping and a way to tell whether a character is compatibility > >> decomposable as input for the algorithmic classification, or a table > >> containing the result of of the classification. Both seem relatively > >> large to me. > > > > Perhaps "no more big tables maintained by the IETF" would resonate better? > > > Did the IETF itself ever maintain one? > There is still the "PRECIS Derived Property Value Registry" mandated by > section 9.1 to be maintained by the IANA, which (as I understand it) is > basicaly the "table containing the result of the classification" that I > mentioned. All stringprep processing was based on a lookup table. In theory, IDNA2008 and PRECIS are based on an algorithm. Yes, there are tables at iana.org, but those are not supposed to be normative. Granted, you still have big tables in Unicode, but not separate tables at iana.org in addition to the base tables of Unicode properties. /psa From florob@babelmonkeys.de Wed Jul 20 14:19:29 2011 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 0B2AF21F8557 for ; Wed, 20 Jul 2011 14:19:29 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8O92UUN0-3mL for ; Wed, 20 Jul 2011 14:19:28 -0700 (PDT) Received: from babelmonkeys.de (unknown [IPv6:2a01:4f8:140:9341:a2b3::ab]) by ietfa.amsl.com (Postfix) with ESMTP id 26EF321F8555 for ; Wed, 20 Jul 2011 14:19:27 -0700 (PDT) Received: from xdsl-87-79-171-25.netcologne.de ([87.79.171.25] helo=[192.168.234.167]) by v64231 with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1QjeAu-0002fy-Jr for precis@ietf.org; Wed, 20 Jul 2011 23:19:24 +0200 Message-ID: <4E274657.3060405@babelmonkeys.de> Date: Wed, 20 Jul 2011 23:19:19 +0200 From: Florian Zeitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110628 Thunderbird/5.0 MIME-Version: 1.0 To: precis@ietf.org References: <4E26F4D9.9000405@babelmonkeys.de> <20110720162701.GA97011@stpeter.im> In-Reply-To: <20110720162701.GA97011@stpeter.im> X-Enigmail-Version: 1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [precis] draft slides for precis-framework 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, 20 Jul 2011 21:19:29 -0000 Am 20.07.2011 18:27, schrieb Peter Saint-Andre: > On Wed, Jul 20, 2011 at 05:31:37PM +0200, Florian Zeitz wrote: >> Am 20.07.2011 17:16, schrieb Joe Hildebrand: >>> Perhaps "no more big tables maintained by the IETF" would resonate better? >>> >> Did the IETF itself ever maintain one? >> There is still the "PRECIS Derived Property Value Registry" mandated by >> section 9.1 to be maintained by the IANA, which (as I understand it) is >> basicaly the "table containing the result of the classification" that I >> mentioned. > > All stringprep processing was based on a lookup table. In theory, IDNA2008 and PRECIS are based on an algorithm. Yes, there are tables at iana.org, but those are not supposed to be normative. Granted, you still have big tables in Unicode, but not separate tables at iana.org in addition to the base tables of Unicode properties. > So, algorith-wise we're switching from a bunch of big custom tables to a huge table maintained by someone else. For implementers caring about code/executable size that's probably about the same. >From a specification/standards point of view I see the merit/your point. BTW what the word for how when you mentioning two things focus always goes to the one you cared less about? ;) From jefsey@jefsey.com Thu Jul 21 18:20:44 2011 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 BECF821F8A6C; Thu, 21 Jul 2011 18:20:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.185 X-Spam-Level: X-Spam-Status: No, score=-100.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a-6MsyiQ3XxI; Thu, 21 Jul 2011 18:20:44 -0700 (PDT) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by ietfa.amsl.com (Postfix) with ESMTP id 1704B21F8A7A; Thu, 21 Jul 2011 18:20:44 -0700 (PDT) Received: from 135.91-227-89.dsl.completel.net ([89.227.91.135]:52511 helo=jfcmsc.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1Qk4Pz-0000ZF-1e; Thu, 21 Jul 2011 18:20:43 -0700 Message-Id: <7.0.1.0.2.20110722022958.05f6bb18@jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 22 Jul 2011 03:14:01 +0200 To: iucg@ietf.org From: JFC Morfin In-Reply-To: <4E274657.3060405@babelmonkeys.de> References: <4E26F4D9.9000405@babelmonkeys.de> <20110720162701.GA97011@stpeter.im> <4E274657.3060405@babelmonkeys.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage2.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: Cc: precis@ietf.org Subject: Re: [precis] draft slides for precis-framework X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 01:20:44 -0000 Apps-discuss teach internationalization needs to their members. http://www.saint-andre.com/ietf/i18n-intro.pdf Then PRECIS (stringprep) has also its set of slides: http://www.saint-andre.com/ietf/ietf81-precis-framework.pdf These two problems are intricated because they share the same problem: the sustainable use of Unicode. At 23:19 20/07/2011, Florian Zeitz wrote: >For implementers caring about code/executable size that's probably >about the same. > From a specification/standards point of view I see the merit/your point. The problem is that Unicode is still an inadequate asolution to support computer network use by real people. And that majuscules are still not supported what makes the whole considered things "senseless" (I mean semantically lame) for Latin languages, in particular French. I did not see the main point quoted in these slides, which is orthotypography. As long as one considers that the Internet is 7 bits ASCII I am afraid we also do not perceive the problem correctly, what means that we will most probably be unable to explore the right solution, whatever it may be. I know getting rid in part of Unicode and changing our reading of the Internet technology is something hardly conceivable, hence inacceptable. However, this is what we just did with IDNA2008. Because everyone wanted to be free from Unicode versioning and users could not accept Internet internal mapping. We now need multilinguisation, i.e. the coexistence of every language on an equal footing and a physhing-proof universal character system. The best stringprep solution is no stringprep. This is RFC 3439 principle of simplicity. I think Unicode is not RFC 3439 conformant, hence all our problems. Sure we need an IETF temporary patch, but we also need a sustainable long term solution. If we do not consider the later, IMHO we will not build a good enough patch. jfc From stpeter@stpeter.im Sun Jul 24 06:35:19 2011 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 ACCF121F855A for ; Sun, 24 Jul 2011 06:35:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XU24yWFZYh-x for ; Sun, 24 Jul 2011 06:35:19 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 22B5C21F84FE for ; Sun, 24 Jul 2011 06:35:19 -0700 (PDT) Received: from squire.local (unknown [198.135.0.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id AED12411FF for ; Sun, 24 Jul 2011 07:36:11 -0600 (MDT) Message-ID: <4E2C1F95.207@stpeter.im> Date: Sun, 24 Jul 2011 09:35:17 -0400 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: precis@ietf.org References: <4E262E6A.8000503@stpeter.im> In-Reply-To: <4E262E6A.8000503@stpeter.im> X-Enigmail-Version: 1.2 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [precis] draft slides for precis-framework X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2011 13:35:19 -0000 On 7/19/11 9:24 PM, Peter Saint-Andre wrote: > I've created somes slides about draft-blanchet-precis-framework for our > discussions next week: > > http://www.saint-andre.com/ietf/ietf81-precis-framework.pdf > > Feedback is welcome. I'll provide a final version to the chairs before > our session on Thursday. Chairs and others, I updated my slides on the plane yesterday. Reload that URL for the latest. Peter -- Peter Saint-Andre https://stpeter.im/ From dthaler@microsoft.com Sun Jul 24 09:34:11 2011 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 0089721F88DD for ; Sun, 24 Jul 2011 09:34:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.543 X-Spam-Level: X-Spam-Status: No, score=-110.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tTM49zMBf0bo for ; Sun, 24 Jul 2011 09:34:10 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id 7A03F21F88B7 for ; Sun, 24 Jul 2011 09:34:10 -0700 (PDT) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Sun, 24 Jul 2011 09:34:10 -0700 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) with Microsoft SMTP Server (TLS) id 14.1.323.2; Sun, 24 Jul 2011 09:34:09 -0700 Received: from TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.59]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.01.0289.008; Sun, 24 Jul 2011 09:34:09 -0700 From: Dave Thaler To: Alexey Melnikov Thread-Topic: [precis] I-D Action: draft-ietf-precis-problem-statement-03.txt Thread-Index: AQHMQCHtIjbY3Ui59U6XkYP32ApnCJToOzIA//+TQ3CACYZ0gIAKaPug Date: Sun, 24 Jul 2011 16:34:08 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B17A8C5@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> References: <20110711232504.17969.21565.idtracker@ietfa.amsl.com> <20110711233420.GB6886@shinkuro.com> <9B57C850BB53634CACEC56EF4853FF653B15F15D@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <4E232ACB.7070105@isode.com> In-Reply-To: <4E232ACB.7070105@isode.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.43] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Andrew Sullivan , "precis@ietf.org" Subject: Re: [precis] I-D Action: draft-ietf-precis-problem-statement-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: Sun, 24 Jul 2011 16:34:11 -0000 Alexey wrote: [...] > Ok, let me try to elaborate on my review and why I wrote what I wrote. I = was > talking specifically about IMAP/POP/SMTP usernames (passwords are > another story). Many email servers support all of the three protocols and > use the same identity format in all three. For a given email address the > corresponding user identity is either the left hand side of the email add= ress > and/or the whole email address. (This isn't documented anywhere, but it i= s > one of the things that all email implementors need to know.) The domain > part (if included) is case-insensitive. SMTP (RFC > 5321) says that the left hand side is case sensitive. In practice this re= striction > turned out to be quite problematic in real deployments (because humans > just don't pay attention to case sometimes) and most of the systems I kno= w > of treat left hand sides as case sensitive.=20 Did you mean to say sensitive or insensitive above? > However until and unless an > update to RFC 5321 declares that all left hand sides of email addresses a= re > case insensitive, we can't say that left hand sides are always case insen= sitive, > as some systems might rely on case sensitivity of left hand sides. >=20 > Does this help? Yes, it clarifies that currently it's Indefinite, and hence dangerous to us= e for many security purposes. (And btw simply declaring that something is case insensitive but not restri= cted to ASCII, is also Indefinite.) Thanks! -Dave From jefsey@jefsey.com Mon Jul 25 14:15:14 2011 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 7F90721F8A57; Mon, 25 Jul 2011 14:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.595 X-Spam-Level: X-Spam-Status: No, score=-100.595 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_20=-0.74, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AU3vN70QYXi7; Mon, 25 Jul 2011 14:15:14 -0700 (PDT) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by ietfa.amsl.com (Postfix) with ESMTP id E4DCA21F89B8; Mon, 25 Jul 2011 14:15:06 -0700 (PDT) Received: from 135.91-227-89.dsl.completel.net ([89.227.91.135]:62589 helo=jfcmsc.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1QlSUP-0006GG-TS; Mon, 25 Jul 2011 14:15:02 -0700 Message-Id: <7.0.1.0.2.20110725192800.06a72ea0@jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 25 Jul 2011 22:59:27 +0200 To: Andrzej Bartosiewicz , Jothan Frakes From: JFC Morfin In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage2.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: Cc: vip@icann.org, precis@ietf.org, iucg@ietf.org Subject: Re: [precis] [vip] Educational session on existing variant practices 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, 25 Jul 2011 21:15:14 -0000 At 09:40 25/07/2011, Andrzej Bartosiewicz wrote: >Sure. I will cover that... Dear Andrzeij, I am not sure this introduction covers the IDNA2008 context? We reach the IDNA2008 consensus due to the RFC 5895 draft, that was further on published for information only as it exemplifies one of the many possible ways to address many different real life problems including mapping, variants, etc. Also, you seem to consider variants only in the TLD and domain name context (without indicating the DNS options). However the problem also affects many other Internet protocols. The WG/PRECIS is chartered to help a solution to replace stringprep in these protocols. Don't you think it would be advisable to present all these issues together? This might help a lot? RFC 1958 states: "If there are several ways of doing the same thing, choose one. If a previous design, in the Internet context or elsewhere, has successfully solved the same problem, choose the same solution unless there is a good technical reason not to. Duplication of the same protocol functionality should be avoided as far as possible, without of course using this argument to reject improvements." So, whatever the technical solution, is there is one, should be the same. Or do you think the variant/homograph problem should only be addressed as a general digital ecosystem scripting issue outside of the Internet context ? An Unicode extension as a script table able to cleanly support any entry without any risk of variant and homograph problem because it would be a graphcode only based upon the geometric graphic form. This would be really sympathetic to me as I think this is the only solution on the long range and that ccTLDs could easily contribute in sending a copy of every symbol they accept in a given script, based upon a common fount. I suppose people like ABBY could also help? This field is very wide, isn't it? Lot of consideration ahead, I am afraid. jfc From jefsey@jefsey.com Tue Jul 26 01:14:06 2011 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 C53ED21F8C19; Tue, 26 Jul 2011 01:14:06 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char E4 hex): To: Patrik F\344ltstr\366m ) id 1Qlcm9-00075R-AP; Tue, 26 Jul 2011 01:14:01 -0700 Message-Id: <7.0.1.0.2.20110726100451.055aac98@jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 26 Jul 2011 10:14:32 +0200 To: Patrik Fältström ,vip@icann.org From: JFC Morfin In-Reply-To: <1C0C9977-F934-4E26-BF53-BC06B6BEB64F@frobbit.se> References: <4E2C83EF.1080209@Yonita.com> <4E2D381C.6050100@Yonita.com> <1C0C9977-F934-4E26-BF53-BC06B6BEB64F@frobbit.se> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage2.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: Cc: precis@ietf.org, iucg@ietf.org Subject: Re: [precis] [vip] Educational session on existing variant practices 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, 26 Jul 2011 08:14:06 -0000 At 09:02 26/07/2011, Patrik Fältström wrote: >On 26 jul 2011, at 08.55, Patrik Fältström wrote: > > > On 25 jul 2011, at 11.32, Andrzej Bartosiewicz wrote: > > > >> I have no problmem with "æ" and "ae" > > > > I do, they are two different things if you are a Swedish speaking. > > > > "æ" and "ä" on the other hand should be treated as the same. > > > > Which is something completely different than "lookalike" of course. > > > > Just to show the confusion. > >Let me add an explanation to the above. > >In English the "æ" is a ligature, and in some more languages. It is >a separate letter and *not* a ligature in the Scandinavian languages >that uses it. > >So whether something is a ligature, and because of that what is "the >same" is context dependent. > > Patrik In such a case, the solution seems to be to use a table where the visual geometric symbol æ can be freely used by people along their own orthotypography of their own language without caring about the ways other languages, cultures, typographies, orthotypographies. Either it is possible to bridge such a graphcode with unicode and we have to do it, or it is not and here is the problem we (VIP, PRECIS, IUCG, ...) have to address. Best jfc From alexey.melnikov@isode.com Tue Jul 26 08:21:44 2011 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 7FEB511E808F for ; Tue, 26 Jul 2011 08:21:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vcXsCvGxEUXx for ; Tue, 26 Jul 2011 08:21:44 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id A7B7F11E808E for ; Tue, 26 Jul 2011 08:21:43 -0700 (PDT) Received: from [130.129.55.138] (dhcp-378a.meeting.ietf.org [130.129.55.138]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 26 Jul 2011 16:21:39 +0100 Message-ID: <4E2ED3EF.5030009@isode.com> Date: Tue, 26 Jul 2011 10:49:19 -0400 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.21) Gecko/20090303 SeaMonkey/1.1.15 To: Dave Thaler References: <20110711232504.17969.21565.idtracker@ietfa.amsl.com> <20110711233420.GB6886@shinkuro.com> <9B57C850BB53634CACEC56EF4853FF653B15F15D@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <4E232ACB.7070105@isode.com> <9B57C850BB53634CACEC56EF4853FF653B17A8C5@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B17A8C5@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Andrew Sullivan , "precis@ietf.org" Subject: Re: [precis] I-D Action: draft-ietf-precis-problem-statement-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: Tue, 26 Jul 2011 15:21:44 -0000 Dave Thaler wrote: > Alexey wrote: > [...] > >> Ok, let me try to elaborate on my review and why I wrote what I wrote. I was >> talking specifically about IMAP/POP/SMTP usernames (passwords are >> another story). Many email servers support all of the three protocols and >> use the same identity format in all three. For a given email address the >> corresponding user identity is either the left hand side of the email address >> and/or the whole email address. (This isn't documented anywhere, but it is >> one of the things that all email implementors need to know.) The domain >> part (if included) is case-insensitive. SMTP (RFC >> 5321) says that the left hand side is case sensitive. In practice this restriction >> turned out to be quite problematic in real deployments (because humans >> just don't pay attention to case sometimes) and most of the systems I know >> of treat left hand sides as case sensitive. >> > Did you mean to say sensitive or insensitive above? > Right, I meant "case insensitive" in the last quoted sentence. >> However until and unless an >> update to RFC 5321 declares that all left hand sides of email addresses are >> case insensitive, we can't say that left hand sides are always case insensitive, >> as some systems might rely on case sensitivity of left hand sides. >> >> Does this help? >> > Yes, it clarifies that currently it's Indefinite, and hence dangerous to use > for many security purposes. > > (And btw simply declaring that something is case insensitive but not restricted > to ASCII, is also Indefinite.) > From stpeter@stpeter.im Thu Jul 28 08:02:35 2011 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 D8B7D21F8C7A for ; Thu, 28 Jul 2011 08:02:35 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7C4OLIH3FMR for ; Thu, 28 Jul 2011 08:02:35 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 7DA1C21F8C6F for ; Thu, 28 Jul 2011 08:02:33 -0700 (PDT) Received: from dhcp-13ac.meeting.ietf.org (unknown [198.135.0.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 5981A410E8 for ; Thu, 28 Jul 2011 09:03:37 -0600 (MDT) Message-ID: <4E317A07.2000706@stpeter.im> Date: Thu, 28 Jul 2011 11:02:31 -0400 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: precis@ietf.org X-Enigmail-Version: 1.2 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [precis] meeting coordinates 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, 28 Jul 2011 15:02:36 -0000 Just a reminder that the PRECIS WG meeting starts in 2 hours. Here is information for remote participants: Audio: http://ietf81streaming.dnsalias.net/ietf/ietf802.m3u Slides: https://datatracker.ietf.org/meeting/81/materials.html#wg-precis Chatroom: xmpp:precis@jabber.ietf.org?join /psa From jefsey@jefsey.com Thu Jul 28 22:26:49 2011 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 BD40621F87AF; Thu, 28 Jul 2011 22:26:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.723 X-Spam-Level: X-Spam-Status: No, score=-101.723 tagged_above=-999 required=5 tests=[AWL=-0.039, BAYES_00=-2.599, J_CHICKENPOX_92=0.6, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r8fjJTcG06Ot; Thu, 28 Jul 2011 22:26:48 -0700 (PDT) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by ietfa.amsl.com (Postfix) with ESMTP id 41D6B21F8794; Thu, 28 Jul 2011 22:26:48 -0700 (PDT) Received: from 162.187-227-89.dsl.completel.net ([89.227.187.162]:54410 helo=jfcmsc.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1Qmfav-0002r6-6o; Thu, 28 Jul 2011 22:26:46 -0700 Message-Id: <7.0.1.0.2.20110727122404.06a73278@jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 29 Jul 2011 07:27:27 +0200 To: internet users contributing group From: JFC Morfin In-Reply-To: References: <20110725215540.GA1878@shinkuro.com> <000601cc4b1e$57944a60$06bcdf20$@mobiry.com> <20110725233019.GK1878@shinkuro.com> <4E2E73E1.2080901@digsys.bg> <6B046E3B-CBE6-43A5-B4FA-7BFBD7A89240@eurid.eu> <7.0.1.0.2.20110727002912.055ab6d8@jefsey.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage2.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: Cc: Giovanni Seppia , precis@ietf.org, "idna-update@alvestrand.no work" , vip@icann.org Subject: [precis] Internet User review: IDNA2008 follow-up at IETF/PRECIS and ICANN/VIP X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 05:26:49 -0000 Jean-Michel, I agree with you. However, things are not that simple. Andrew Sullivan asked for an algorithm and he is right: machines and systems need algorithms. What you emphasize is that in our cases (Variants, Stringprep replacement, IDNA support on the user side, extended services naming, IUsers' expectations, etc.) the algorithmic nature is just as precise as the mathematical algorithm that Andrew expects, but it obeys an entirely different logic because it also involves a brain to brain level. We have the tool (fringe to fringe as permitted by IDNA2008 and exemplified in RFC 5895) to support it but we first have to understand and document this logic. Therefore, we first need to get everyone who shares this burden to accept that their approach is to be shared with others and to understand that their logic and the logic of the others will help, but that the final logic cannot be a common logic. It is a new logic to we have to explore in common. Their experience and the experience of the others are needed but the case that we have to address is totally new. That case first needs to be understood. IPv6 is to give everyone millions of sub addresses (we call them IDv6, IIDs that are globally addressable). People will from then on allocate one, or several, thousand domain names to themselves, in the same way that they used to have an address, a name, a nickname, a mobile directory of addresses, TV channels, file names, etc. Therefore, we are talking of a world digital ecosystem naming intrastructure of hundreds of billions of domain names plus mail names, login ID, passwords, keys, codes, etc. In addition, we the users want this to be simple, sure, and secure for everyone in every language and every orthotypography (an orthotypographic requirement that IDNA2008 adequately refused to include in the network side in refusing mapping and ICANN calls "variants" on the user side). Compared to this, IDNA2008 was a _very_ simple thing to achieve. Now, you have summarized your vision of the VIP, WG/PRECIS, IAB, and IUCG problem in a metaductive manner. IMHO, this is correct. Metaduction is the proper and only way to address a problem of this size and complexity as a way to think in networks. However, metaduction is a way of thinking that everybody partly uses all the time but that is still only explored as such, at least in the way you use it, within our ALFA (Architecture Libre/Free Architecture) research framework. Some have emphasized that there was a deep need for a common glossary. Yes! However, the target is not only to use the same glossary, but also to have a common understanding of the ways of thinking of the concerned parties (engineers, operators, users). Therefore, let me explain it and translate what you mean to others, then analyze what you state and what it might imply in order to address these groups' needs, as they result from our IDNA2008 final consensus. At 10:39 27/07/2011, jean-michel bernier de portzamparc wrote: >Jefsey, > >I read your mails and compare them with our discussions. What I feel >is that we progressively switch to and from the three forms of >comparison, we call semantical (sense) as opposed to mathematical >(one character at a time) and physical (same external form). These three types belong to what we are exploring as "intelligent thinking" in order to address complexity, as an alternative to Edgar Morin's "complex thinking". Complex means woven, (complexus: canvas in Latin), like the web. Intelligent thinking is based on the idea that there are three(+one) levels of intelligence: 1. physical, like the Internet lines and nodes, 2. logical/mathematical, like the protocols, 3.1. semantical, like the meaning of what is exchanged. 3.2 pragmatical, like a paradigm (everyone thinks the same): This corresponds to : 1. "to be in good intelligence with" and interlinks, 2. "intelligence" (as in the CIA) as information and command of the hyperlinks, 3.1. be intelligent, i.e. to be able to adequately use that information in modeling (comprehending) it and observing/emulating the model behavior. 3.2. the same but when instead of considering a single semantic processors one considers a semantic processor network: a crowd, country, culture, community, etc. Here, the reasoning cannot be classical deduction, induction, abduction,or even hypothetico-deduction. We call it metaduction. It consists in building a brain vision, a mental map of what we understand. We call it an ontography (because 50% of the brain uses vision related functions, e.g. "theory" means an observation, we refer to our "points of view", etc.). The legend of this "map" is an ontology. Then, the metaductive reasoning consists in observing the mental map and progressing through it. This is truly mentally walking a theory. One, therefore, understands that metaduction extensively uses contextual models, and that being dependent on models makes it totally dependent on context, i.e. on the adjacencies that define a context (or in IDNA2008 terms and thinking environment: "joiners" and "CONTEXTO"). As a consequence, when - physical logic is built on correspondence - and mathematical logic is built on equivalence - then semantical logic is built on coherence - and pragmatical logic is, in addition, dependent on internal consistency. (note: pragmatic is semantic in a context, i.e. considering the influence/interference of a given relational space and therefore of its referent [an exemple of referent is the IANA, which up to now was unique, however the Internet technology defines one IANA per DNS class]). Communications are about exchanging (uttering/understanding) our "maps" with others. Our first needs are, therefore, to name, locate, protect, and access our "maps" in a simple, sure, and secure manner. This is what WG/PRECIS and ICANN/VIP attempt to do. This is a part of the IDNA2008 consequences that I proposed to discuss two years ago and that led me to appeal the IAB against the IESG's lack of warning about the consequences of IDNA2008 when publishing the RFC set. Let me remind you here that the outcome of these appeals was extremely positive as they identified that this issue extended far outside the area of responsibility of the IETF since it concerns the whole digital ecosystem, even though IDNA2008 bluntly reminded us about the true, very larger extent of the Internet architecture. In this digital ecosystem, the Internet legacy proposition/contribution does: - name in using domain names, login, etc., - locate in using IP addresses, - protect in encrypting, - access in using keywords, etc. - deal with transmitting datagrams as efficiently as possible (this is end to end connectivity) - want that "Everything else should be done at the fringes" (RFC 1958: Architectural Principles of the Internet). IDNA2008 has clarified what, in diversity support, is: - at the end to end (protocol) level (RFC set) - and at a fringe to fringe intelligent level that the IETF never documented before. This is why the RFC 5895, which permitted our IDNA2008 consensus, was published only for informational purposes. Because its matter was "unusual" for the IETF: "this document does not specify the behavior of a protocol that appears 'on the wire'. It describes an operation that is to be applied to user input in order to prepare that user input for use in an "on the network" protocol. As unusual as this may be for a document concerning Internet protocols, it is necessary to describe this operation". - and permitted this way to support what is at the brain to brain, human semantic and pragmatic level. IDNA has removed constraints on the Internet architectural support of diversity (while considering the case of the linguistic diversity), hence of complexity. In so doing, it also modified our reading of the Internet architecture: it showed that the Internet is also built on the principle of subsidiarity (in addition to the principle of constant change [RFC 1958] and of the principle of simplicity [RFC 3439: Some Internet Architectural Guidelines and Philosophy]). The consequence that we are faced with is threefold: 1. we have to adapt to IDNA2008 changes and update ourselves and the technology to the IDNA2008 unleashed opportunities. 2. we are in an open architectural context that we are not familiar with, however it only results from a full reading of the RFCs that we know as well as from a full use of the very unchanged code that we use every day. The danger is that we can consider solutions that are already provided or contradict them without noticing it. This was the case of IDNA2003. This still is the case of the IDNA concept (RFC 6055). 3. the architectural context that we call the IUI (cf. below) i.e. the Internet Use Interface on the Internet side of it, and the Intelligent Use Interface on our user side, is something that we will also intelligently use (i.e. with our same intelligence and need for simplicity, surety and security) with other technologies we should consider (mobile phones, regular mail, registries, etc.). We are not used to their standardization except common users. While implicitly simplicity, surety and security on our user side calls for an advisable unicity (RFC 1958) in the coherence and consistency of the proposed solutions. This should be helped by the use of the same IDNA2008 on the Internet side and our demand of a single follow-up on this Internet side: this is why, as users, we wish for the same common liaison and work between the "sons of IDNA2008", like VIP, PRECIS, IUCG, and IDNABis experience, etc. >This is a plex. Yes. A plex is a network of ideas. This is the very nature of complexity. A plex is a plex of a plex etc. We observe that metaduction, as introduced above, is not about reducing complexity into small simpler problems (rationalism) because one loses the influence of the complexity (the whole is more than the addition of its parts because parts lose the whole when being split from other parts). Metaduction is about looking at confusion as a whole, to progressively map it, to study the map when looking for its apices (plural of apex) of complication and simplicity, i.e. what seems to be the most difficult to understand and what seems to be the simplest to do to clarify things. This is a pure application of RFC 3439: in very large systems one must apply the principle of simplicity. > It meshes domain name, variants, phishing, meanings, sounds, > feelings, perceptions, etc. This is human communication vs. machine > communications. Object communications - as we know them, are based upon geometric correspondence: translation, forgetting the size or not. Machine communications - as we know them, are based upon the mathematical comparison function: equivalence, equality, if then else. Human communications - want to use machines acting as peripheral simplificators (operators of complexity simplification) are based upon the semantical comparison function: coherence - or on its pragmatic similitude. IDNA2008 has established an interface between these three forms of communications in the way that it establishes the relation between the Internet and applications, which in turn need an interface with the Internet. This middleware is what permits us, the users, to use the Internet in the way we want. This middleware will also be present when we deal with any other digitized communications technology this is why we used to call it the Intelligent Use Interface (IUI) and have started exploring it in parallel to IDNA2008. >We therefore need to address it as a plex, metasimplify it and find >its apex of simplicity. Yes. This is the process that I introduced above. However, metaduction is not the way the IETF, ICANN, etc. think. This was acknowledged by ICANN in a very interesting fundamental document named ICP-3. http://www.icann.org/en/icp/icp-3.htm. It states that the Internet community proceeds through experimentation. Therefore, ICANN called for community experimentation. This was in 2001.. It seems that we were alone in carrying it out. Except for Google, which by its size can do something equivalent at any time with http://code.google.com/intl/fr/speed/public-dns/ their Public DNS. We do not discuss an alternative root or so on, or the extension of the root. We are speaking about a full true implementation of the DNS itself, the way it is documented and in the light IDNA2008 unconstrains it. . > I think that clarifying what "string" means in the three types of > comparisons would help a lot. > >Physical : same frequency >Mathematical : same components >Semantical : same what? You have to also consider the Pragmatic alternative to Semantic; There are community side effects in what is discussed. A "Variant" as per VIP could be what is related to Pragmatic. The term could be used. >A way to address this point would be to look for another word than >"string" that would lead people to identify the differences with a >mathematical string in terms of comparison. You have to also consider the Pragmatic alternative to Semantic; There are community side effects in what is discussed. A "Variant" as per VIP could be what is related to Pragmatic. The term could be used. And we could define it along similitude grades depending on contexts A way to address this point would be to look for a word other than "string" that would lead people to identify the differences with a mathematical string in terms of comparison. >Also, to decide if their comparison is correspondence, equivalence >or coherence. This makes sense. This is a common approach to start with more appropriated and identified definitions. It is also to decide if their comparison is correspondence, equivalence, or coherence. Or rather acceptance in the pragmatic case. >This way we can use the principle of correspondence to check where we are. The principle of correspondence states that innovation in science must not only explain new aspects but also keep explaining these that were already explained. This is the IDNA prerequisite and what IDNA2008 guaranteed: the DNS as we know it and it is deployed millions of times, operational protocols, and users' satisfaction MUST not be affected. Thank you. Now we have to agree upon a new word to qualify a "smart string" if a "dumb string" is something we cannot read (spell) but only see. This means that: - a "dumb string" (symbol) supports a signal - a "string" supports content - a "smart string" to supports a thought. I would propose using "sememe", with a coherence seme by seme: http://en.wikipedia.org/wiki/Seme_%28semantics%29. - a "local smart string" to support a relational space's accepted "pragmeme" between a "pract" and an "allopract" (cf.pragmatician experts). Let me be clear, if we accept that: The last two propositions cannot be processed by a machine in a way that an RFC can describe, but an RFC can describe a common procedure and the guidelines for such a process to be carried by common agreement. We have a good example in the way Unicode code-points are worked out, langtag tables are built, ccTLDs are defined, etc. I suggest that we work on this and add these definitions to our glossary. Then, I think we should start from Marc Blanchet's Draft http://www.ietf.org/id/draft-blanchet-precis-framework-02.txt and discuss if a graphcode approach could address his requirements. Note: I use the concept of "graphcode" for a stringprep replacing algorithm made of a table of character graphical symbols for every existing script: one (phishing proof) symbol per geometric form. Each graph-point corresponds to a number of "in-code-points", and to one single "out-code-point" per orthotypography. This is a pragmatic equivalent of RFC 5892, i.e. the algorithm is not processed by a computer program but by a multibrain consensus. Then, the resulting code-graph (equivalent to code-point in a graphcode) system could be implemented for a test at one of the layers of the ML-DNS. Note: The ML-DNS is an IDNA2008 conformant encapsulation of the DNS that we are exploring (testing is to be carried before being documented), to process a naming pile that is able to address the people's final needs. This pile is the pile of the variants of the same name in various classes and presentations, e.g. A-label, U-label, UDN (user actual entry), etc. A major difference with the IDNA context is that the ML-DNS supports a single "IDNApplication service" per machine (single resolution source). However, frankly, my first and main concern is that your approach confirms that these three (VIP, PRECIS, and IUCG) groups are working on things very similar and quite intricate. They do need to relate in a way or another. At least, as the users of their deliverables, we need to ensure that they do. The work that they are engaged in is revamping Shannon's communications theory in a multilingual human context. It is worth some consideration. jfc From yoshiro.yoneya@jprs.co.jp Sun Jul 31 22:50:22 2011 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 A201F11E8070 for ; Sun, 31 Jul 2011 22:50:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.657 X-Spam-Level: X-Spam-Status: No, score=-99.657 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGAzRxU8dGjx for ; Sun, 31 Jul 2011 22:50:22 -0700 (PDT) Received: from send12.jprs.co.jp (send12.jprs.co.jp [IPv6:2001:df0:8:6::72]) by ietfa.amsl.com (Postfix) with ESMTP id 51FDD11E8071 for ; Sun, 31 Jul 2011 22:50:21 -0700 (PDT) Received: from sendsms12.jprs.co.jp (sendsms12.jprs.co.jp [202.11.17.114]) by send12.jprs.co.jp (8.13.8+Sun/8.13.8) with ESMTP id p715oNnQ016048 for ; Mon, 1 Aug 2011 14:50:23 +0900 (JST) Received: from sendsms12.jprs.co.jp (unknown [127.0.0.1]) by sendsms12.jprs.co.jp (Symantec Mail Security) with ESMTP id 95DBB34DA for ; Mon, 1 Aug 2011 14:50:23 +0900 (JST) X-AuditID: ca0b1172-00000009000010a3-3e-4e363e9e57ec Received: from NOTE550 (off-cpu04.tyo.jprs.co.jp [172.18.4.14]) by sendsms12.jprs.co.jp (Symantec Mail Security) with SMTP id F089534D6 for ; Mon, 1 Aug 2011 14:50:22 +0900 (JST) Date: Mon, 1 Aug 2011 14:50:20 +0900 From: Yoshiro YONEYA To: precis@ietf.org Message-Id: <20110801145020.13011915.yoshiro.yoneya@jprs.co.jp> In-Reply-To: <20110713144254.9fa0f03c.yoshiro.yoneya@jprs.co.jp> References: <20110713144254.9fa0f03c.yoshiro.yoneya@jprs.co.jp> X-Mailer: Sylpheed 3.1.1 (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: AAAAAA== Subject: [precis] IETF81 Quebec draft minutes X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 05:50:22 -0000 Dear all, Following is draft minutes of IETF 81 Quebec City. Please review and give your comments to the chairs. IETF81 Precis wg meeting minutes Quebec City, Canada 2011-07-28 13:00-14:30 Problem Statement - Blobclass is useful for a string not to process at all, is a distinction from freeclass. - Table in Appendix A is useful. - Next steps is to include the stringprep references reviews. Framework - SecretClass should allow symbols and punctuations, and clear guidance will be helpful. Suggestion to have an IETF BCP on i18n passwords. Given that the base class might be used by many IETF protocols, defining the allowed set of codepoints shall be defined by security community. - Bidi rule is refering RFC 5983. - Usefullness of subclassing is up to precis customers. - Chairs should assign someone to research and get some general answers to mappings. - For confusables, document should explicitly mention about registration policy. Issue of multiple version of unicode in different clients and what to do. Should be written somewhere. The charter talks about guidance. Might need to move around text between framework and guidance document. - Consensus on adopting framework document as WG document. - Next step is to do a new rev with draft-ietf-precis and then forward to security community for input on secretclass. Marc & Yoneya, co-chairs -- Yoshiro YONEYA