From yoshiro.yoneya@jprs.co.jp Thu Feb 7 18:01:26 2013 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69C681F0D07 for ; Thu, 7 Feb 2013 18:01:26 -0800 (PST) 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 Ry6K+DlzADDw for ; Thu, 7 Feb 2013 18:01:26 -0800 (PST) Received: from off-send01.tyo.jprs.co.jp (off-send01.tyo.jprs.co.jp [IPv6:2001:df0:8:17::10]) by ietfa.amsl.com (Postfix) with ESMTP id B49051F0D0A for ; Thu, 7 Feb 2013 18:01:25 -0800 (PST) Received: from off-sendsmg01.tyo.jprs.co.jp (off-sendsmg01.tyo.jprs.co.jp [172.18.8.32]) by off-send01.tyo.jprs.co.jp (8.13.8/8.13.8) with ESMTP id r1821L6O001416 for ; Fri, 8 Feb 2013 11:01:24 +0900 X-AuditID: ac120820-b7fec6d000005acc-95-51145c74fdef Received: from NOTE550 (off-cpu04.tyo.jprs.co.jp [172.18.4.14]) by off-sendsmg01.tyo.jprs.co.jp (Symantec Messaging Gateway) with SMTP id 7B.E7.23244.47C54115; Fri, 8 Feb 2013 11:01:24 +0900 (JST) Date: Fri, 8 Feb 2013 11:01:22 +0900 From: Yoshiro YONEYA To: precis@ietf.org Message-Id: <20130208110122.a4fd8514d5a4904d3f63e9f8@jprs.co.jp> X-Mailer: Sylpheed 3.3.0 (GTK+ 2.10.14; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKIsWRmVeSWpSXmKPExsWyRoiFT7ckRiTQYEWvkMWu739YHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsWbqR9aCO5wVc9Z9YW5gfM3excjJISFgIvGl6S6ULSZx4d56 ti5GLg4hgeOMEg9/7QZKcHCwCKhI3HpiCVLDJmAg8WvZbyYQW0RAWOLW7YWsILawgJvEzrdP GEFsXgEHibVr30DNtJC40NQBNoZXQFDi7w5hkDCzgBbQ9FssELa8xPa3c5gnMPLMQqiahaRq FpKqBYzMqxhl8tPSdItT81KKc9MNDPVKKvP1sgqKivWSQfQmRnCocCjsYJxxyuAQowAHoxIP b8814UAh1sSy4srcQ4ySHExKorzpwSKBQnxJ+SmVGYnFGfFFpTmpxYcYJTiYlUR4I9SBcrwp iZVVqUX5MClpDhYlcd7jZ3f4CQmkJ5akZqemFqQWwWRlODiUJHhNooEaBYtS01Mr0jJzShDS TBycIMN5gIZzgdTwFhck5hZnpkPkTzFKSonzLooCSgiAJDJK8+B6XzGKA70gzDsRpI0HGPdw Xa+ABjIBDVyfKQwysCQRISXVwCjlt0g3ZLtHmrk/X4i0xR6WP5/72W4oWjhtvuAu4Z0wVXCj SWdzq7z459dL0jdzndtddEA5s+m1urOCrD9jsdVNoRnJ6XtFDLonnF6gWPx0Gu9D5s8sDZfl fxnYRd0MCivc6lql4RVYv/JmfOSyxjurlV3jDn8/8imnhlVPSro68r0A19bFSizFGYmGWsxF xYkAREM0RLgCAAA= Subject: [precis] Fw: precis - Requested session has been scheduled for IETF 86 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, 08 Feb 2013 02:01:26 -0000 Dear all, FYI. Please note that the schedule may change. If you have agenda item, please let know. Regards, -- Yoshiro YONEYA Begin forwarded message: Date: Thu, 07 Feb 2013 17:18:41 -0800 From: "\"IETF Secretariat\"" To: yoshiro.yoneya@jprs.co.jp Cc: precis-ads@tools.ietf.org, Marc.Blanchet@viagenie.ca, yoshiro.yoneya@jprs.co.jp, wlo@amsl.com Subject: precis - Requested session has been scheduled for IETF 86 Dear Yoshiro Yoneya, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. precis Session 1 (2:00:00) Thursday, Afternoon Session I 1300-1500 Room Name: Boca 1 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Area Name: Session Requester: Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 35 Conflicts to Avoid: First Priority: appsawg apparea eai iri saag storm xmpp sunset4 Second Priority: websec Special Requests: --------------------------------------------------------- From yoshiro.yoneya@jprs.co.jp Mon Feb 11 21:41:42 2013 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07A4921F8BD7 for ; Mon, 11 Feb 2013 21:41:42 -0800 (PST) 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 yeMndcdVqAwC for ; Mon, 11 Feb 2013 21:41:41 -0800 (PST) Received: from off-send01.tyo.jprs.co.jp (off-send01.tyo.jprs.co.jp [IPv6:2001:df0:8:17::10]) by ietfa.amsl.com (Postfix) with ESMTP id BAEA921F8BCE for ; Mon, 11 Feb 2013 21:41:40 -0800 (PST) Received: from off-sendsmg01.tyo.jprs.co.jp (off-sendsmg01.tyo.jprs.co.jp [172.18.8.32]) by off-send01.tyo.jprs.co.jp (8.13.8/8.13.8) with ESMTP id r1C5fcu0019578 for ; Tue, 12 Feb 2013 14:41:39 +0900 X-AuditID: ac120820-b7fec6d000005acc-bc-5119d613acfb Received: from NOTE550 (off-cpu04.tyo.jprs.co.jp [172.18.4.14]) by off-sendsmg01.tyo.jprs.co.jp (Symantec Messaging Gateway) with SMTP id E5.80.23244.316D9115; Tue, 12 Feb 2013 14:41:39 +0900 (JST) Date: Tue, 12 Feb 2013 14:41:39 +0900 From: Yoshiro YONEYA To: precis@ietf.org Message-Id: <20130212144139.6c62cd0e0e02e97b4d5a3691@jprs.co.jp> In-Reply-To: <20130208110122.a4fd8514d5a4904d3f63e9f8@jprs.co.jp> References: <20130208110122.a4fd8514d5a4904d3f63e9f8@jprs.co.jp> X-Mailer: Sylpheed 3.3.0 (GTK+ 2.10.14; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDIsWRmVeSWpSXmKPExsWyRoiFT1f4mmSgwebp8ha7vv9hdWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxupvK9gKrvBWvPk2i6mB8RlXFyMnh4SAicSi74cYIWwxiQv3 1rOB2EICxxklrnZ5dTFycLAIqEosuycDEmYTMJD4tew3E4gtIiAscev2QlYQW1ggVKJn6x0w m1fAQaJn/iywkZwCjhILXm9jhhjpIPH25G0WiFUWEheaOthBxvMKCEr83SEMEmYW0JJ4+OsW C4QtL7H97RzmCYx8sxCqZiGpmoWkagEj8ypGmfy0NN3i1LyU4tx0A0O9ksp8vayComK9ZBC9 iREcWBwKOxhnnDI4xCjAwajEwztBRjJQiDWxrLgy9xCjJAeTkijv2stAIb6k/JTKjMTijPii 0pzU4kOMEhzMSiK8yz5KBArxpiRWVqUW5cOkpDlYlMR5j5/d4SckkJ5YkpqdmlqQWgSTleHg UJLgfXMFaKhgUWp6akVaZk4JQpqJgxNkOA/Q8I8gNbzFBYm5xZnpEPlTjJJS4rxMV4ESAiCJ jNI8uN5XjOJALwjz/gdp4wEmCbiuV0ADmYAGcuaIgwwsSURISTUwRvOV/rSd9vtpVt/Zi92T PkSXVrM+jZt76tytmd++qDPf2erhLtVj7h874cHLZy7PFV5zPhExtOveV9bRFbmJ607u9g1H WIVMci/fPqJwPFmXIzxZdr3fnpfvX7VMXBXzZbdM3xEmtUDr8HWVtum+pYlvBfnvM77RdPw3 5WFk/TztvQEOfq/6lViKMxINtZiLihMBEqMV8c8CAAA= Subject: Re: [precis] Fw: precis - Requested session has been scheduled for IETF 86 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 Feb 2013 05:41:42 -0000 Is there anyone who want to join the meeting remotely? If there, please let know ASAP. Regards, -- Yoshiro YONEYA On Fri, 8 Feb 2013 11:01:22 +0900 Yoshiro YONEYA wrote: > Dear all, > > FYI. Please note that the schedule may change. > If you have agenda item, please let know. > > Regards, > > -- > Yoshiro YONEYA > > Begin forwarded message: > > Date: Thu, 07 Feb 2013 17:18:41 -0800 > From: "\"IETF Secretariat\"" > To: yoshiro.yoneya@jprs.co.jp > Cc: precis-ads@tools.ietf.org, Marc.Blanchet@viagenie.ca, yoshiro.yoneya@jprs.co.jp, wlo@amsl.com > Subject: precis - Requested session has been scheduled for IETF 86 > > > Dear Yoshiro Yoneya, > > The session(s) that you have requested have been scheduled. > Below is the scheduled session information followed by > the original request. > > precis Session 1 (2:00:00) > Thursday, Afternoon Session I 1300-1500 > Room Name: Boca 1 > --------------------------------------------- > > > > Request Information: > > > --------------------------------------------------------- > Working Group Name: > Area Name: > Session Requester: > > Number of Sessions: 1 > Length of Session(s): 2 Hours > Number of Attendees: 35 > Conflicts to Avoid: > First Priority: appsawg apparea eai iri saag storm xmpp sunset4 > Second Priority: websec > > > > Special Requests: > > --------------------------------------------------------- > > > > > _______________________________________________ > precis mailing list > precis@ietf.org > https://www.ietf.org/mailman/listinfo/precis > > From internet-drafts@ietf.org Wed Feb 13 20:24:43 2013 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F8F921F85E8; Wed, 13 Feb 2013 20:24:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 9SE8Id84ew5m; Wed, 13 Feb 2013 20:24:43 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23FEA21F85EB; Wed, 13 Feb 2013 20:24:43 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130214042443.5506.25683.idtracker@ietfa.amsl.com> Date: Wed, 13 Feb 2013 20:24:43 -0800 Cc: precis@ietf.org Subject: [precis] I-D Action: draft-ietf-precis-saslprepbis-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: Thu, 14 Feb 2013 04:24:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Preparation and Comparison of Internation= alized Strings Working Group of the IETF. Title : Preparation and Comparison of Internationalized Strings = Representing Simple User Names and Passwords Author(s) : Peter Saint-Andre Alexey Melnikov Filename : draft-ietf-precis-saslprepbis-00.txt Pages : 12 Date : 2013-02-13 Abstract: This document describes how to handle Unicode strings representing simple user names and passwords, primarily for purposes of comparison. This profile is intended to be used by Simple Authentication and Security Layer (SASL) mechanisms (such as PLAIN and SCRAM-SHA-1), as well as other protocols that exchange simple user names or passwords. This document obsoletes RFC 4013. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-precis-saslprepbis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-precis-saslprepbis-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From t.nemo10@kmd.keio.ac.jp Sat Feb 16 18:40:49 2013 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC9821F8439 for ; Sat, 16 Feb 2013 18:40:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 vpED2vL4aq3b for ; Sat, 16 Feb 2013 18:40:48 -0800 (PST) Received: from mail.kmd.keio.ac.jp (mail.kmd.keio.ac.jp [IPv6:2001:200:167:2e90::164]) by ietfa.amsl.com (Postfix) with ESMTP id BD20E21F8421 for ; Sat, 16 Feb 2013 18:40:47 -0800 (PST) Received: from host266.kmd.keio.ac.jp (host266.kmd.keio.ac.jp [131.113.137.10]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.kmd.keio.ac.jp (Postfix) with ESMTPSA id 1C2C5805A8 for ; Sun, 17 Feb 2013 11:40:45 +0900 (JST) From: Takahiro Nemoto Content-Type: multipart/alternative; boundary="Apple-Mail=_1689A33F-F55B-4D08-9480-7FB288CA71F8" Message-Id: Date: Sun, 17 Feb 2013 11:40:54 +0900 To: "precis@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [precis] Mappings document's open issues 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 Feb 2013 02:40:49 -0000 --Apple-Mail=_1689A33F-F55B-4D08-9480-7FB288CA71F8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-2022-jp Dear all, Yoneya-san and I listed open issues for draft-ietf-precis-mappings. Please read and give your comments/suggestions. Followings are current mappings document's open issues. 1. Whether is local case mapping belong in additional mappings in = precis framework? 2. If local case mapping belong in precis framework, it's necessary = to specify mapping order=20 as local case mapping then case mapping. Because it makes no sense to perform local case mapping after case = mapping. 3. Handling order of precis framework and precis mappings is = ambiguous. =20 It's necessary to define the order in precis framework or in this = document or in both documents. And followings are authors=1B$B!G=1B(B recommended solutions. 1. Additional mapping should be mappings which are not included in = Mappings document. 2. Handling order is Mappings document then processes in precis = framework document. 3. The order should be defined in both documents. Regards, Nemo -- Takahiro Nemoto t.nemo10@kmd.keio.ac.jp --Apple-Mail=_1689A33F-F55B-4D08-9480-7FB288CA71F8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-2022-jp
t.nemo10@kmd.keio.ac.jp
<= div>



= --Apple-Mail=_1689A33F-F55B-4D08-9480-7FB288CA71F8-- From stpeter@stpeter.im Sat Feb 16 20:52:58 2013 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C99C21F86C9 for ; Sat, 16 Feb 2013 20:52:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.006, 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 K4Aco+TeHR+U for ; Sat, 16 Feb 2013 20:52:57 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id BBDCD21F8574 for ; Sat, 16 Feb 2013 20:52:55 -0800 (PST) Received: from [192.168.1.4] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 93926403CD; Sat, 16 Feb 2013 22:00:11 -0700 (MST) Message-ID: <51206227.407@stpeter.im> Date: Sat, 16 Feb 2013 21:52:55 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Takahiro Nemoto References: In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "precis@ietf.org" Subject: Re: [precis] Mappings document's open issues 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 Feb 2013 04:52:58 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Nemo, thanks for raising these open issues. I need to read draft-ietf-precis-mappings-01 again quite carefully, but here is some quick feedback. On 2/16/13 7:40 PM, Takahiro Nemoto wrote: > Dear all, > > Yoneya-san and I listed open issues for > draft-ietf-precis-mappings. Please read and give your > comments/suggestions. > > Followings are current mappings document's open issues. > > 1. Whether is local case mapping belong in additional mappings in > precis framework? The "additional mapping" sections of the framework document do not specify what those mappings might be (e.g., local case mapping, special mapping, delimiter mapping, width mapping). Do you suggest that we add those particular mappings to the framework? > 2. If local case mapping belong in precis framework, it's > necessary to specify mapping order as local case mapping then case > mapping. It is true that we need to specify the order of mappings. This is the case no matter whether local case mapping (and the other "additional mappings") is specified in the framework or elsewhere. > Because it makes no sense to perform local case mapping after case > mapping. I agree. > 3. Handling order of precis framework and precis mappings is > ambiguous. It's necessary to define the order in precis framework > or in this document or in both documents. > > And followings are authors’ recommended solutions. > > 1. Additional mapping should be mappings which are not included in > Mappings document. Do you mean "in framework document"? > 2. Handling order is Mappings document then processes in precis > framework document. Agreed. That's not what the framework document says right now (at the end of Section 3.1): NOTE: In order to ensure proper comparison, any normalization MUST be completed before the application of additional mappings or the process of checking whether a code point is valid, disallowed, or unassigned. > 3. The order should be defined in both documents. That seems like a good idea, although I think the framework ought to be the guiding document. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRIGImAAoJEOoGpJErxa2pTSYP/1bSQO5GTT8eHFUW1ZDafMoO rFesB4ndTBNYGN4sSs+WSfuscO7YyKTQvTxpcMm0CdcOCdhss5kgXx69Csmb12DG t6Qfp2janN3tM6Ufp+iSHHGxuvu32aqr3W5KYV8CxCSiLQmtHYAoelSeIrPkS8pg +nCqpaCWbU0tvmj/t+MNx3+nzMUrgQNda77pLPnb860nnNoc6iIXU3zmnoapi75X 2HsG5Wr5PZ4Fd2MLTs5h0b116LP/OYn5FZ6thqTTXHdwx/rzrNv05tVQ9/yjQJCV MS8+hJDsaeYaRRMGacKx63AQiq2Gzz48a7tgmn7UYpim4paGNTkced62oNuHbd2P sgb6XmAyKUcmhUp4IEh3V3jOy7EZSJveL8hmwG6ZEmWu35oL8kfLjh8mlXoTsJac /8tWCQqUd/x754TRN408LJNz/EjHfufb+nqSK87c5p99073tf5LMik8527Z+PMVe MnuAaBrZ52VMqMve3H9PcxTWbGIQiZffdK0F2uyzQ3lPqXMDNikNhn9OphHOURrh f1IDSJz7Q5tEJsh4NPYv/nsL60nVvXYRnf2eFd36SH1wHo9ZoD38NsUIbOnoYVQ6 yfL4o8znMuZy7PCj/hE30PQ++R5unUhHGsvGQ6MatLp2mM9uXVb8FkzG2ZuJNcwP 1zKwC79oA76QnftIsiqT =XYIB -----END PGP SIGNATURE----- From stpeter@stpeter.im Mon Feb 18 13:20:34 2013 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36B5B21F8C86; Mon, 18 Feb 2013 13:20:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.514 X-Spam-Level: X-Spam-Status: No, score=-102.514 tagged_above=-999 required=5 tests=[AWL=0.085, 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 wvCYMBVP4wiW; Mon, 18 Feb 2013 13:20:33 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id EBF3721F8C84; Mon, 18 Feb 2013 13:20:29 -0800 (PST) Received: from [10.129.24.65] (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 7ACC4403CD; Mon, 18 Feb 2013 14:27:51 -0700 (MST) Message-ID: <51229B19.1080703@stpeter.im> Date: Mon, 18 Feb 2013 14:20:25 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Chris Newman References: <20130214042443.5506.25683.idtracker@ietfa.amsl.com> <511D0B9C.7060102@stpeter.im> <06DA1F509463BB680806A11E@96B2F16665FF96BAE59E9B90> <511D5350.5000009@stpeter.im> <511D5601.4050509@stpeter.im> <29A69AF46F677183C2C75C29@96B2F16665FF96BAE59E9B90> In-Reply-To: <29A69AF46F677183C2C75C29@96B2F16665FF96BAE59E9B90> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org, "precis@ietf.org" Subject: Re: [precis] [kitten] Fwd: I-D Action: draft-ietf-precis-saslprepbis-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, 18 Feb 2013 21:20:34 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [ + precis@ietf.org ] On 2/18/13 11:04 AM, Chris Newman wrote: > --On February 14, 2013 14:24:17 -0700 Peter Saint-Andre > wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> >> On 2/14/13 2:12 PM, Peter Saint-Andre wrote: >>> Hi Chris, thank you for the review. >>> >>> On 2/14/13 12:37 PM, Chris Newman wrote: >>>> A common construction for user names on the Internet is the >>>> form "user@example.com", specifically, a subset of >>>> email-address syntax with an embedded domain name is commonly >>>> used for login identity strings (although theses login >>>> identity strings may or may not be usable as actual email >>>> addresses). >>> >>>> As a result, the character class used for user names used >>>> for authentication needs to be a superset of the character >>>> class used for domain names. I was not able to tell from the >>>> specification if that was the case. If it isn't, I believe >>>> that should be fixed. >>> >>> It is the case, because all characters in the ASCII range are >>> grandfathered into the PRECIS NameClass. Thus some examples >>> are definitely in order! We'll add those to the next version. >> >> I propose adding the second paragraph shown below to the end of >> Section 2.1, which defines the handling of simple user names: >> >> Note well that all code points and blocks not explicitly allowed >> in the PRECIS NameClass are disallowed; this includes private >> use characters, surrogate code points, and the other code points >> and blocks defined as "Prohibited Output" in Section 2.3 of RFC >> 4013. >> >> However, all characters in the ASCII range are "grandfathered" >> into the PRECIS NameClass. As a result, common constructions >> such as "user@example.com" are allowed as simple user names when >> using software that conforms to this specification, as they were >> under [RFC4013]. > > I don't see this as a necessary addition. It was quite clear from > the specifications that the ASCII range was grandfathered in > NameClass. It appears I was unclear in stating my concern, let me > try again to explain my concern. Yes, I did misconstrue your question. > My concern is that login identities should be able to contain a > valid IDNA U-label. It is not clear to me if NameClass permits all > valid U-labels. If it does not, then I believe using NameClass for > login identities is a mistake. The user@exmaple.com form for login > identities will continue to be useful as the infrastructure is > expanded to allow UTF-8 characters in both the "user" part and the > "example.com" part of that form. If we disallow valid U-labels in > login identities then we break the multi-domain model for lots of > software out there and will force that software to change its > architecture when it adopts this technology or to choose not to > adopt this technology. If valid IDNA U-labels are permitted in > login identities then implementers can keep their current > architecture and adopt saslprepbis. Ah, I see. You raise a good question. The intent was that any code point allowed in IDNs would be allowed in the PRECIS NameClass, but looking closely at draft-ietf-precis-framework I realize that the intent might not be reflected in the spec right now. I will investigate further and post again when I have something definitive to report. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRIpsYAAoJEOoGpJErxa2pUXsP/iwzE9yQtKkn0aeVaccNneVn xDNeWfXGjfdcKE9K5nqyQgH5WTVX180RMZ9p4TZk8C0E4k7o+8PxPZF2ua/Sth+w 4hg8DMGn0zPvoiQoL4gklMXxKZn5ADU5iMP6KTcdSnCXjZkHPezbZ7Q2CQDe3u5j pxQnR6rw6jL/jcUbDucvSMJ0mJKtoHMgG7LTxlmC3jhWZ+SZyUdk38HpDC1e71b3 LdnS77OgUEJdDkDoCdj89ByDNefVeC2FkD6a/MbnLr9TbcMNzGNtwX0dM4x5sTIB GUywXzzmwU409tf7xlurC5wcBtffFL8lhbkYziv0X2C5RHZ5waevrHG9Tkzl7f2F 0Vs8QgtwZqlCvR+9ByJzmT1FW966cOUGQaYahNLjNtzUzzgZ4Oyvfdw6g5NxxM3V jTBqW8YF/QOF2ZYYfwpw99Mc5hPuNzs6l65g8Q8R394+JmCtyh5MY5ycgmpykrIN qAMzCefbz0PnP1gwTsOyQG31JsmSXTu4FwB5rfCFZJqKgnvXFHUrDyuh/AbW/su0 RmlA5WOBhem1b2MgbttWD8sxNvWbkVhlRsOQZymZaJFeejlyCV2MTQIWvy4Q6G7g I2aSLpMSp01wNGDRTxMmloFg8tsWDyxUjaz8AE7BFCpPGjDAddzuuIYlPFVubD4A Z/e5nXrXsqAwOjIUQYai =I/k2 -----END PGP SIGNATURE----- From stpeter@stpeter.im Mon Feb 18 21:05:41 2013 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77C0021F8DC3; Mon, 18 Feb 2013 21:05:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.283 X-Spam-Level: X-Spam-Status: No, score=-103.283 tagged_above=-999 required=5 tests=[AWL=0.716, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_37=0.6, 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 Yb9p9dz75BIy; Mon, 18 Feb 2013 21:05:40 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id C241121F8DB9; Mon, 18 Feb 2013 21:05:38 -0800 (PST) Received: from [192.168.1.3] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 5C694403CD; Mon, 18 Feb 2013 22:13:01 -0700 (MST) Message-ID: <51230821.8080904@stpeter.im> Date: Mon, 18 Feb 2013 22:05:37 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Chris Newman References: <20130214042443.5506.25683.idtracker@ietfa.amsl.com> <511D0B9C.7060102@stpeter.im> <06DA1F509463BB680806A11E@96B2F16665FF96BAE59E9B90> <511D5350.5000009@stpeter.im> <511D5601.4050509@stpeter.im> <29A69AF46F677183C2C75C29@96B2F16665FF96BAE59E9B90> <51229B19.1080703@stpeter.im> In-Reply-To: <51229B19.1080703@stpeter.im> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org, "precis@ietf.org" Subject: Re: [precis] [kitten] Fwd: I-D Action: draft-ietf-precis-saslprepbis-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: Tue, 19 Feb 2013 05:05:41 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2/18/13 2:20 PM, Peter Saint-Andre wrote: > [ + precis@ietf.org ] > > On 2/18/13 11:04 AM, Chris Newman wrote: >> --On February 14, 2013 14:24:17 -0700 Peter Saint-Andre >> wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>> >>> On 2/14/13 2:12 PM, Peter Saint-Andre wrote: >>>> Hi Chris, thank you for the review. >>>> >>>> On 2/14/13 12:37 PM, Chris Newman wrote: >>>>> A common construction for user names on the Internet is >>>>> the form "user@example.com", specifically, a subset of >>>>> email-address syntax with an embedded domain name is >>>>> commonly used for login identity strings (although theses >>>>> login identity strings may or may not be usable as actual >>>>> email addresses). >>>> >>>>> As a result, the character class used for user names used >>>>> for authentication needs to be a superset of the character >>>>> class used for domain names. I was not able to tell from >>>>> the specification if that was the case. If it isn't, I >>>>> believe that should be fixed. >>>> >>>> It is the case, because all characters in the ASCII range are >>>> grandfathered into the PRECIS NameClass. Thus some examples >>>> are definitely in order! We'll add those to the next >>>> version. >>> >>> I propose adding the second paragraph shown below to the end of >>> Section 2.1, which defines the handling of simple user names: >>> >>> Note well that all code points and blocks not explicitly >>> allowed in the PRECIS NameClass are disallowed; this includes >>> private use characters, surrogate code points, and the other >>> code points and blocks defined as "Prohibited Output" in >>> Section 2.3 of RFC 4013. >>> >>> However, all characters in the ASCII range are "grandfathered" >>> into the PRECIS NameClass. As a result, common constructions >>> such as "user@example.com" are allowed as simple user names >>> when using software that conforms to this specification, as >>> they were under [RFC4013]. > >> I don't see this as a necessary addition. It was quite clear >> from the specifications that the ASCII range was grandfathered >> in NameClass. It appears I was unclear in stating my concern, let >> me try again to explain my concern. > > Yes, I did misconstrue your question. > >> My concern is that login identities should be able to contain a >> valid IDNA U-label. It is not clear to me if NameClass permits >> all valid U-labels. If it does not, then I believe using >> NameClass for login identities is a mistake. The user@exmaple.com >> form for login identities will continue to be useful as the >> infrastructure is expanded to allow UTF-8 characters in both the >> "user" part and the "example.com" part of that form. If we >> disallow valid U-labels in login identities then we break the >> multi-domain model for lots of software out there and will force >> that software to change its architecture when it adopts this >> technology or to choose not to adopt this technology. If valid >> IDNA U-labels are permitted in login identities then implementers >> can keep their current architecture and adopt saslprepbis. > > Ah, I see. You raise a good question. The intent was that any code > point allowed in IDNs would be allowed in the PRECIS NameClass, > but looking closely at draft-ietf-precis-framework I realize that > the intent might not be reflected in the spec right now. I will > investigate further and post again when I have something definitive > to report. Hi Chris, I've been thinking about this further... IMHO this is similar to the previous discussion about naming needing to include space characters (after all, your name is "Chris Newman", not "ChrisNewman"). After much discussion, participants in the PRECIS WG concluded that it would be safer to disallow space characters in the NameClass, and that application protocols would need to define their constructs as a space-separated series of NameClass instances. And in fact that's what we've done in draft-ietf-precis-saslprepbis: simpleusername = simplepart [1*(1*SP simplepart)] simplepart = 1*(namepoint) ; ; a "namepoint" is a UTF-8 encoded ; Unicode code point that conforms to ; the "NameClass" string class defined ; in draft-ietf-precis-framework ; Here I see something similar: in order to allow strings like user@host.tld, an application protocol would need to define its constucts along these lines: userathost = userpart '@' domainpart userpart = 1*(namepoint) ; ; a "namepoint" is a UTF-8 encoded ; Unicode code point that conforms to ; the "NameClass" string class defined ; in draft-ietf-precis-framework ; domainpart = IP-literal / IPv4address / ifqdn ifqdn = 1*64(domainpoint) ; ; a "domainpoint" is a UTF-8 encoded ; Unicode code point that conforms to ; RFC 5890 ; Or, naturally, we could allow both styles (and others). That said, we might want to allow some characters into the NameClass that are outside LetterDigits ("A") in RFC 5892. I'm thinking especially of some of the code points in Exceptions ("F"). This sounds like an appropriate topic for discussion in Orlando... Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRIwggAAoJEOoGpJErxa2pW5wP/jWNKPKRPSm9JX/pgP6e8SVx oxme9tEb/mw9ryW+bv343Ut46HX53EfVZnV1nUoxOexSP3TCJmViUQFgCTiD/wi5 r/UV8XqU0l1cSfxW0zyZEFG0BcFt64ggzg/e9GigKWEnKZBgZJqMNb3+urGmz9d3 BN6bIWEBBV57RSDcYPOTe10Wrq2H27AZerDxcYVn02BRM4iFM9RLSVIFfM0QwkeX d1JRjYt9lhtNJkxMhNV6BS17z5g8H0w/Fhl96DWpxdQTWAETiybgz9LI1bpNsS59 IFrxkPWThUvUB/NUyIK1mFIrQq5FkJ3owT6S+Xg4ude/uXLWoOcExA6141dpguoS 0WGesk7jeN/6NUiPKX4oNMc4dd1fVOQlu/rFCY3+0hACTdT5xVLtJ69dRlb4hrmx rmLKfOA8CljV/3NN4eYBDnQd6og66I1BanEJ/A9KuwWpTi8EEehbkejkc0B6FZyl K9HKbEcu4iWDoOMGlRoKb7ApLKi3sW5GN44aqpwQRiZw4goIzlNJReubp64HdtoZ mss9iPVY2V11JykVxKCGKMJ/WpnHLZtOmsrfIt6tjONsw9npQPlOm5XqktLjasR8 cobeV0qg9x8gJkT1oaZKbEjctPAZh7fz3H+i0EcTsTjOs0fjJTU30osUzAZTPIoq VM4sgvjRuE4vfbtnkJXw =6LeL -----END PGP SIGNATURE----- From t.nemo10@kmd.keio.ac.jp Mon Feb 18 21:41:15 2013 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08B3521F8D33 for ; Mon, 18 Feb 2013 21:41:15 -0800 (PST) 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=[AWL=0.001, 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 OMiYSUfUSBst for ; Mon, 18 Feb 2013 21:41:13 -0800 (PST) Received: from mail.kmd.keio.ac.jp (mail.kmd.keio.ac.jp [IPv6:2001:200:167:2e90::164]) by ietfa.amsl.com (Postfix) with ESMTP id 72D551F0D07 for ; Mon, 18 Feb 2013 21:41:12 -0800 (PST) Received: from host266.kmd.keio.ac.jp (host266.kmd.keio.ac.jp [131.113.137.10]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.kmd.keio.ac.jp (Postfix) with ESMTPSA id 3A3C28056B; Tue, 19 Feb 2013 14:41:06 +0900 (JST) Content-Type: text/plain; charset=iso-2022-jp Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Takahiro Nemoto In-Reply-To: <51206227.407@stpeter.im> Date: Tue, 19 Feb 2013 14:41:06 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51206227.407@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1499) Cc: "precis@ietf.org" Subject: Re: [precis] Mappings document's open issues 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 Feb 2013 05:41:15 -0000 Hello Peter-san, thank you for your feedback. Our comment is following. Please make sure. On 2013/02/17, at 13:52, Peter Saint-Andre wrote: >=20 > On 2/16/13 7:40 PM, Takahiro Nemoto wrote: >> Dear all, >>=20 >> Yoneya-san and I listed open issues for >> draft-ietf-precis-mappings. Please read and give your >> comments/suggestions. >>=20 >> Followings are current mappings document's open issues. >>=20 >> 1. Whether is local case mapping belong in additional mappings in >> precis framework? >=20 > The "additional mapping" sections of the framework document do not > specify what those mappings might be (e.g., local case mapping, > special mapping, delimiter mapping, width mapping). Do you suggest > that we add those particular mappings to the framework? No, we don't. We think those particular mappings, that are described in mappings = document,=20 are pre-preparation process performed before the framework like RFC5895. >=20 >> 2. If local case mapping belong in precis framework, it's >> necessary to specify mapping order as local case mapping then case >> mapping. >=20 > It is true that we need to specify the order of mappings. This is the > case no matter whether local case mapping (and the other "additional > mappings") is specified in the framework or elsewhere. Thanks. We already specified the order in mappings document. >=20 >> Because it makes no sense to perform local case mapping after case >> mapping. >=20 > I agree. >=20 >> 3. Handling order of precis framework and precis mappings is >> ambiguous. It's necessary to define the order in precis framework >> or in this document or in both documents. >>=20 >> And followings are authors=1B$B!G=1B(B recommended solutions. >>=20 >> 1. Additional mapping should be mappings which are not included in >> Mappings document. >=20 > Do you mean "in framework document"? No, we don't.=20 We think additional mapping of framework is mappings other than in = mappings document. >=20 >> 2. Handling order is Mappings document then processes in precis >> framework document. >=20 > Agreed. That's not what the framework document says right now (at the > end of Section 3.1): >=20 > NOTE: In order to ensure proper comparison, any normalization MUST = be > completed before the application of additional mappings or the > process of checking whether a code point is valid, disallowed, or > unassigned. Thanks. >=20 >> 3. The order should be defined in both documents. >=20 > That seems like a good idea, although I think the framework ought to > be the guiding document. Do you mean "the mappings document" ought to be the guiding document? Regards, Nemo -- Takahiro Nemoto t.nemo10@kmd.keio.ac.jp= From nico@cryptonector.com Tue Feb 19 14:46:30 2013 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFB9121E803A; Tue, 19 Feb 2013 14:46:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.776 X-Spam-Level: X-Spam-Status: No, score=-3.776 tagged_above=-999 required=5 tests=[AWL=-1.799, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 ICtgIP6PxKYo; Tue, 19 Feb 2013 14:46:30 -0800 (PST) Received: from homiemail-a97.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 2A28921F8873; Tue, 19 Feb 2013 14:46:30 -0800 (PST) Received: from homiemail-a97.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a97.g.dreamhost.com (Postfix) with ESMTP id EF19128605B; Tue, 19 Feb 2013 14:46:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=01dFfScI5bq1IRDauVGV TOQISMg=; b=XxYkUMLGmwMTBStzGb2HYfCO9PbxP6dHPlcbTiDwM+dfcXJxRhG3 QFowVdripMtXhp8ZVssfZIZqoR3LFZ/qxXqzBn1Z9o213tpux1HFSMLGHuQ2o8qE I7EMud99ItOOM3p+Za/jcJFM8WoQjBpEiaUg3PDCCh7DfO7fcoXYDtY= Received: from mail-ia0-f178.google.com (mail-ia0-f178.google.com [209.85.210.178]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a97.g.dreamhost.com (Postfix) with ESMTPSA id B6C2B286057; Tue, 19 Feb 2013 14:46:29 -0800 (PST) Received: by mail-ia0-f178.google.com with SMTP id y26so6519938iab.37 for ; Tue, 19 Feb 2013 14:46:29 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.88.168 with SMTP id bh8mr1028797igb.67.1361313989178; Tue, 19 Feb 2013 14:46:29 -0800 (PST) Received: by 10.64.102.201 with HTTP; Tue, 19 Feb 2013 14:46:29 -0800 (PST) In-Reply-To: <51230821.8080904@stpeter.im> References: <20130214042443.5506.25683.idtracker@ietfa.amsl.com> <511D0B9C.7060102@stpeter.im> <06DA1F509463BB680806A11E@96B2F16665FF96BAE59E9B90> <511D5350.5000009@stpeter.im> <511D5601.4050509@stpeter.im> <29A69AF46F677183C2C75C29@96B2F16665FF96BAE59E9B90> <51229B19.1080703@stpeter.im> <51230821.8080904@stpeter.im> Date: Tue, 19 Feb 2013 16:46:29 -0600 Message-ID: From: Nico Williams To: Peter Saint-Andre Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Tue, 19 Feb 2013 15:27:31 -0800 Cc: kitten@ietf.org, Chris Newman , "precis@ietf.org" Subject: Re: [precis] [kitten] Fwd: I-D Action: draft-ietf-precis-saslprepbis-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: Tue, 19 Feb 2013 22:46:30 -0000 On Mon, Feb 18, 2013 at 11:05 PM, Peter Saint-Andre wrote: > IMHO this is similar to the previous discussion about naming needing > to include space characters (after all, your name is "Chris Newman", > not "ChrisNewman"). After much discussion, participants in the PRECIS > WG concluded that it would be safer to disallow space characters in > the NameClass, and that application protocols would need to define > their constructs as a space-separated series of NameClass instances. > And in fact that's what we've done in draft-ietf-precis-saslprepbis: I think this is a mistake. There are plenty of online games where users are allowed to have fairly arbitrary names. E.g., bzflag (although in recent years I think additional restrictions have been added on the registration side). Online gaming is probably a desired customer for SASL -- why not? I think restrictions on user naming should be imposed primarily by the registrar, not by the client or server software. We might well advise against allowing whitespace in usernames, and we might need to map different whitespace codepoints to just one, and so on, but not prohibit. Nico -- From stpeter@stpeter.im Tue Feb 19 18:30:55 2013 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 703A321F8853; Tue, 19 Feb 2013 18:30:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.611 X-Spam-Level: X-Spam-Status: No, score=-102.611 tagged_above=-999 required=5 tests=[AWL=-0.012, 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 sgkTJXRY+MNH; Tue, 19 Feb 2013 18:30:54 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 964F921F87BA; Tue, 19 Feb 2013 18:30:54 -0800 (PST) Received: from [192.168.1.6] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 26B3E4004E; Tue, 19 Feb 2013 19:38:20 -0700 (MST) Message-ID: <5124355B.8000707@stpeter.im> Date: Tue, 19 Feb 2013 19:30:51 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: Nico Williams References: <20130214042443.5506.25683.idtracker@ietfa.amsl.com> <511D0B9C.7060102@stpeter.im> <06DA1F509463BB680806A11E@96B2F16665FF96BAE59E9B90> <511D5350.5000009@stpeter.im> <511D5601.4050509@stpeter.im> <29A69AF46F677183C2C75C29@96B2F16665FF96BAE59E9B90> <51229B19.1080703@stpeter.im> <51230821.8080904@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org, Chris Newman , "precis@ietf.org" Subject: Re: [precis] [kitten] Fwd: I-D Action: draft-ietf-precis-saslprepbis-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: Wed, 20 Feb 2013 02:30:55 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2/19/13 3:46 PM, Nico Williams wrote: > On Mon, Feb 18, 2013 at 11:05 PM, Peter Saint-Andre > wrote: >> IMHO this is similar to the previous discussion about naming >> needing to include space characters (after all, your name is >> "Chris Newman", not "ChrisNewman"). After much discussion, >> participants in the PRECIS WG concluded that it would be safer >> to disallow space characters in the NameClass, and that >> application protocols would need to define their constructs as a >> space-separated series of NameClass instances. And in fact >> that's what we've done in draft-ietf-precis-saslprepbis: > > I think this is a mistake. There are plenty of online games where > users are allowed to have fairly arbitrary names. E.g., bzflag > (although in recent years I think additional restrictions have been > added on the registration side). Online gaming is probably a > desired customer for SASL -- why not? > > I think restrictions on user naming should be imposed primarily by > the registrar, not by the client or server software. We might > well advise against allowing whitespace in usernames, and we might > need to map different whitespace codepoints to just one, and so on, > but not prohibit. Hi Nico, please (re-)read Section 4.3 of draft-ietf-precis-framework before concluding that the participants in the PRECIS WG are utterly misguided on the issue of whitespace. :-) Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRJDVbAAoJEOoGpJErxa2pq0QP/3AxlkOkRL6IDPWQ39ffcxnQ 3PqkH9PFUEIvD+S20kOZX2aVokGvcwQiZ0GiGXDumTkhTvMxNie47ZmNLaEikExY 4JENZWKZEhz/mfCJZ0PpM7CfpOelt1PCJ8Qne4BiyJObKYso4vFEr/9j43/9WNGL rUxCCkk6AjQ7dUx64bZOc7c+LBvmb1034XYY4HGRihfYCz+nWFSpaMSWtrD0o1Cj iYjZfPa+IUzEjF6QvEB22RkMhQgr3lnyRq++Rhl/iBV6N7Ul0Sie9or879d1/GU2 6iPb8HwAJT8NGBQlv9rp+T/A9XFwRe761NUR2qlLgBbzuO0He5UlyuRetHrVvM/q oZehWeX5wkRQWvwRFxF64A8JRRAoJxj6xOnzHI7yZo4M+75vWf8vrJsPWzU81OAk CTSAuanpwDhfhZpWWUtHNDiJgzFql0oc0/x1nXRrgA+hNtjyV98SWfveuk16tFUo XD7ETDDK+ION/G9QK0FJF6eidMuq6e++OEI/jBfTiUZ+5RpO1DE5VG2dzGRnl8sO SnMZhCcpuwZFoMitr3Hc/chPq9ai29xIt+rnLfghvrTVz36q0hEBjpBl7cCtnPS9 9g18zs03aNWQcOQpiRfmMvY0wLpBuSjOiuPTfx8cT/15htIQOTz/c1fhoY7Z65GZ RdmAKnIZFk7876ATpofQ =uys8 -----END PGP SIGNATURE----- From nico@cryptonector.com Tue Feb 19 19:16:38 2013 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9C4221F886F; Tue, 19 Feb 2013 19:16:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.654 X-Spam-Level: X-Spam-Status: No, score=-3.654 tagged_above=-999 required=5 tests=[AWL=-1.677, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 9Nn8po5Gu58Q; Tue, 19 Feb 2013 19:16:38 -0800 (PST) Received: from homiemail-a27.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id 2C25F21F8818; Tue, 19 Feb 2013 19:16:38 -0800 (PST) Received: from homiemail-a27.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTP id 8EDC3598058; Tue, 19 Feb 2013 19:16:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=QSNNWZJNPFtC+MhIxO6o yvZ39EE=; b=YGk2k8EFBeR8hv8bq0uYesQ9UW8WIbugQbjPt51LvEzJz+RGLE5S X78Oy0lG0nd2T84M/pZD5ujCzet2SPRdaifDm2Af14IBr9OiLiLqAtIImtlPePhN RzsKsjP3ygsGZYr1559WLAffeH8iDqCzvyuvCQ2XJ2yZvJAUP+fqUmQ= Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTPSA id 01A25598057; Tue, 19 Feb 2013 19:16:36 -0800 (PST) Received: by mail-wi0-f170.google.com with SMTP id hm11so5898910wib.5 for ; Tue, 19 Feb 2013 19:16:35 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.194.58.202 with SMTP id t10mr22143734wjq.4.1361330195638; Tue, 19 Feb 2013 19:16:35 -0800 (PST) Received: by 10.216.254.217 with HTTP; Tue, 19 Feb 2013 19:16:35 -0800 (PST) In-Reply-To: <5124355B.8000707@stpeter.im> References: <20130214042443.5506.25683.idtracker@ietfa.amsl.com> <511D0B9C.7060102@stpeter.im> <06DA1F509463BB680806A11E@96B2F16665FF96BAE59E9B90> <511D5350.5000009@stpeter.im> <511D5601.4050509@stpeter.im> <29A69AF46F677183C2C75C29@96B2F16665FF96BAE59E9B90> <51229B19.1080703@stpeter.im> <51230821.8080904@stpeter.im> <5124355B.8000707@stpeter.im> Date: Tue, 19 Feb 2013 21:16:35 -0600 Message-ID: From: Nico Williams To: Peter Saint-Andre Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org, Chris Newman , "precis@ietf.org" Subject: Re: [precis] [kitten] Fwd: I-D Action: draft-ietf-precis-saslprepbis-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: Wed, 20 Feb 2013 03:16:39 -0000 On Tue, Feb 19, 2013 at 8:30 PM, Peter Saint-Andre wrote: > On 2/19/13 3:46 PM, Nico Williams wrote: >> On Mon, Feb 18, 2013 at 11:05 PM, Peter Saint-Andre >> wrote: >>> IMHO this is similar to the previous discussion about naming >>> needing to include space characters (after all, your name is >>> "Chris Newman", not "ChrisNewman"). After much discussion, >>> participants in the PRECIS WG concluded that it would be safer >>> to disallow space characters in the NameClass, and that >>> application protocols would need to define their constructs as a >>> space-separated series of NameClass instances. And in fact >>> that's what we've done in draft-ietf-precis-saslprepbis: >> >> I think this is a mistake. There are plenty of online games where >> users are allowed to have fairly arbitrary names. E.g., bzflag >> (although in recent years I think additional restrictions have been >> added on the registration side). Online gaming is probably a >> desired customer for SASL -- why not? >> >> I think restrictions on user naming should be imposed primarily by >> the registrar, not by the client or server software. We might >> well advise against allowing whitespace in usernames, and we might >> need to map different whitespace codepoints to just one, and so on, >> but not prohibit. > > Hi Nico, please (re-)read Section 4.3 of draft-ietf-precis-framework > before concluding that the participants in the PRECIS WG are utterly > misguided on the issue of whitespace. :-) I said what now? :) But OK, I read that, and I remain unconvinced. What am I missing? If they did have a clue then they didn't write text that I find convincing. Who cares if some devices produce whitespace other than ASCII space? That's what mappings are for. Or maybe I'm missing something. Assume I'm partly ignorant here. What am I missing? Nico -- From chris.newman@oracle.com Tue Feb 19 21:47:45 2013 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9563A21F86FC; Tue, 19 Feb 2013 21:47:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.449 X-Spam-Level: X-Spam-Status: No, score=-107.449 tagged_above=-999 required=5 tests=[AWL=1.150, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4, 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 pCTANxRKoncr; Tue, 19 Feb 2013 21:47:39 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 65FB021F8921; Tue, 19 Feb 2013 21:47:38 -0800 (PST) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r1K5laNC023671 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 20 Feb 2013 05:47:37 GMT Received: from gotmail.us.oracle.com (gotmail.us.oracle.com [10.133.152.174]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r1K5laST014565; Wed, 20 Feb 2013 05:47:36 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from [10.159.103.84] (dhcp-amer-vpn-rmdc-anyconnect-10-159-103-84.vpn.oracle.com [10.159.103.84]) by gotmail.us.oracle.com (Oracle Communications Messaging Server 7u5-28.16(7.0.5.28.0) 64bit (built Dec 16 2012)) with ESMTPA id <0MII00B0C839RL00@gotmail.us.oracle.com>; Tue, 19 Feb 2013 21:47:35 -0800 (PST) Date: Tue, 19 Feb 2013 21:47:33 -0800 From: Chris Newman To: Peter Saint-Andre Message-id: In-reply-to: <51230821.8080904@stpeter.im> References: <20130214042443.5506.25683.idtracker@ietfa.amsl.com> <511D0B9C.7060102@stpeter.im> <06DA1F509463BB680806A11E@96B2F16665FF96BAE59E9B90> <511D5350.5000009@stpeter.im> <511D5601.4050509@stpeter.im> <29A69AF46F677183C2C75C29@96B2F16665FF96BAE59E9B90> <51229B19.1080703@stpeter.im> <51230821.8080904@stpeter.im> X-Mailer: Mulberry/4.0.8 (Mac OS X) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-Mailman-Approved-At: Tue, 19 Feb 2013 22:01:36 -0800 Cc: kitten@ietf.org, precis@ietf.org Subject: Re: [precis] [kitten] Fwd: I-D Action: draft-ietf-precis-saslprepbis-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: Wed, 20 Feb 2013 05:47:46 -0000 --On February 18, 2013 22:05:37 -0700 Peter Saint-Andre wrote: > Here I see something similar: in order to allow strings like > user@host.tld, an application protocol would need to define its > constucts along these lines: Historically, Internet login identities have been freeform ASCII or UTF-8 strings. Widely deployed implementations have sometimes used other charsets such as ISO-8859-1 even when it violates the standards. This shows need for both UTF-8 support and validity enforcement in login identities. Identity systems can impose additional structure as needed. A site's identity system works best if it can span multiple protocols (e.g., IMAP, POP, SMTP, XMPP, web form logins, etc). Architecturally, I think identity systems are best viewed as independent of the consuming protocols even if a lot of software is not implemented that way today. So I'd prefer to avoid having application protocols imposing unnecessary constraints on identity systems. So we're balancing a need for validity enforcement for interoperability (which is the intent behind NameClass) with a need for application protocols to avoid breaking existing identity system models so it is possible for this standard to deploy. This looks like a good engineering problem to me. :-) > That said, we might want to allow some characters into the NameClass > that are outside LetterDigits ("A") in RFC 5892. I'm thinking > especially of some of the code points in Exceptions ("F"). This sounds > like an appropriate topic for discussion in Orlando... Yes, I think that would be a good discussion to have. I would propose that all the PVALID and CONTEXT characters from Exceptions (F) be added to NameClass and state that implementations MAY enforce the CONTEXT restrictions from RFC 5892. - Chris From yoshiro.yoneya@jprs.co.jp Mon Feb 25 20:55:56 2013 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E87221E8181 for ; Mon, 25 Feb 2013 20:55:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b9MCiP-cdfnq for ; Mon, 25 Feb 2013 20:55:56 -0800 (PST) Received: from off-send01.tyo.jprs.co.jp (off-send01.tyo.jprs.co.jp [IPv6:2001:df0:8:17::10]) by ietfa.amsl.com (Postfix) with ESMTP id C13D321E816D for ; Mon, 25 Feb 2013 20:55:55 -0800 (PST) Received: from off-sendsmg01.tyo.jprs.co.jp (off-sendsmg01.tyo.jprs.co.jp [172.18.8.32]) by off-send01.tyo.jprs.co.jp (8.13.8/8.13.8) with ESMTP id r1Q4tsxH027769 for ; Tue, 26 Feb 2013 13:55:54 +0900 X-AuditID: ac120820-b7fec6d000005acc-67-512c405ac3b8 Received: from NOTE550 (off-cpu04.tyo.jprs.co.jp [172.18.4.14]) by off-sendsmg01.tyo.jprs.co.jp (Symantec Messaging Gateway) with SMTP id 2B.BF.23244.A504C215; Tue, 26 Feb 2013 13:55:54 +0900 (JST) Date: Tue, 26 Feb 2013 13:55:59 +0900 From: Yoshiro YONEYA To: precis@ietf.org Message-Id: <20130226135559.8501a3bd772760842f4df5be@jprs.co.jp> X-Mailer: Sylpheed 3.3.0 (GTK+ 2.10.14; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGIsWRmVeSWpSXmKPExsWyRoiFTzfKQSfQ4OoaTYtd3/+wOjB6LFny kymAMYrLJiU1J7MstUjfLoEr482Hb2wF3ewVt/csYG1gvMPaxcjJISFgIrFw9UwmCFtM4sK9 9WxdjFwcQgLHGSVWnzzJDpJgEVCVWPnjKwuIzSZgIPFr2W+wBhEBYYlbtxeCDRIWUJF4uvgh I4jNK+AgMWvpFEaIoRYSF5o6gOZwAMUFJf7uEAYJMwtoSTz8dYsFwpaX2P52DvMERp5ZCFWz kFTNQlK1gJF5FaNMflqabnFqXkpxbrqBoV5JZb5eVkFRsV4yiN7ECA4WDoUdjDNOGRxiFOBg VOLh7ZmoHSjEmlhWXJl7iFGSg0lJlHeGtU6gEF9SfkplRmJxRnxRaU5q8SFGCQ5mJRFezgyg ct6UxMqq1KJ8mJQ0B4uSOO/xszv8hATSE0tSs1NTC1KLYLIyHBxKEryL7ICGChalpqdWpGXm lCCkmTg4QYbzAA2fDFLDW1yQmFucmQ6RP8UoKSXO6wKSEABJZJTmwfW+YhQHekGY1xQkywOM fLiuV0ADmYAGLhIBuba4JBEhJdXAOKH4lOebSnuhgzdu8czNNNv0JePN0/RytxU/b0VvU59l 27LVPrHyd+Pmo4nXfv5aKbBokbv23gi3otKoTUvkP+ztfLakXaLvzA7rxUruVUbVt4+ucuvy ntWZsr29ZtnFs5lrW10U9budpRrKtkRf/+8wV+pMHGvpq8gnDRMd+4+ePL31uQqDohJLcUai oRZzUXEiAFxztj+5AgAA Subject: [precis] IETF86 Orlando draft agenda X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 04:55:56 -0000 Dear all, Following is draft agenda for IETF 86 Orlando. Please send comments/additions/changes to the chairs. 1. Administrativia 2. Document updates / Discussion 2.1 WG I-Ds (1) Framework https://datatracker.ietf.org/doc/draft-ietf-precis-framework/ (2) Preparation and Comparison of Nicknames https://datatracker.ietf.org/doc/draft-ietf-precis-nickname/ (3) Mapping characters for precis classes http://datatracker.ietf.org/doc/draft-ietf-precis-mappings/ (4) Preparation and Comparison of Internationalized Strings Representing Simple User Names and Passwords http://datatracker.ietf.org/doc/draft-ietf-precis-saslprepbis/ 2.2 Individual Documents (1) precis implementation report https://datatracker.ietf.org/doc/draft-nemoto-precis-framework-implement-report/ 3. Next steps Marc & Yoneya, co-chairs From stpeter@stpeter.im Mon Feb 25 21:22:55 2013 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 039D921E8186 for ; Mon, 25 Feb 2013 21:22:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, 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 0EfN+8i09HQ0 for ; Mon, 25 Feb 2013 21:22:54 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id CC5BD21E8160 for ; Mon, 25 Feb 2013 21:22:53 -0800 (PST) Received: from [192.168.1.6] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id EF6524004E; Mon, 25 Feb 2013 22:30:32 -0700 (MST) Message-ID: <512C46AE.4050005@stpeter.im> Date: Mon, 25 Feb 2013 22:22:54 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: Yoshiro YONEYA References: <20130226135559.8501a3bd772760842f4df5be@jprs.co.jp> In-Reply-To: <20130226135559.8501a3bd772760842f4df5be@jprs.co.jp> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: precis@ietf.org Subject: Re: [precis] IETF86 Orlando draft agenda X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 05:22:55 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2/25/13 9:55 PM, Yoshiro YONEYA wrote: > Dear all, > > Following is draft agenda for IETF 86 Orlando. Please send > comments/additions/changes to the chairs. > > 1. Administrativia > > 2. Document updates / Discussion 2.1 WG I-Ds (1) Framework > https://datatracker.ietf.org/doc/draft-ietf-precis-framework/ See below. > (2) Preparation and Comparison of Nicknames > https://datatracker.ietf.org/doc/draft-ietf-precis-nickname/ No open issues here AFAIK. > (3) Mapping characters for precis classes > http://datatracker.ietf.org/doc/draft-ietf-precis-mappings/ > > (4) Preparation and Comparison of Internationalized Strings > Representing Simple User Names and Passwords > http://datatracker.ietf.org/doc/draft-ietf-precis-saslprepbis/ I see one major issue with saslprepbis, raised by Chris Newman, about whether to allow IDNA characters in NameClass. See recent list discussion. I think we need to discuss this in person at the Orlando meeting. Note that this has an impact on the framework, too. > 2.2 Individual Documents (1) precis implementation report > https://datatracker.ietf.org/doc/draft-nemoto-precis-framework-implement-report/ I > need to re-read that one and the mappings spec again... Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRLEatAAoJEOoGpJErxa2pU9sQAKHpvKuiH3fNjEsNA6UzP0B1 EAMJHGtbgN+dy5OjAD7DYJp0AJes6eAuwa+JPZtARK/2bv4cLHUv6NK3Sv/VMdxl tM/AjX7Jvm08bafpK7J3KY/lWtxkgh0zUz7fuMiUdgMNt0kxJNk2uMiCAWOyS2DP cROdIZDJuPfmGbSX7Kx+7W4DIjFoOUl/278BcXrJDpywHOmQoAxPBlLQmY3qDvxN r3CXeIyUqIWQ1OnYjEUs64tbHSIJb4TFwMepCH+FBoG3nk72ekUsjvv+uWvu+w7p QPPBJ10M0kIvX0jDv7nO0VdmeRsgDaBMwHts5nsf0tDsXwP1dc2hX7Gagf+4zRd7 Y2pJb5FNfQfpLVUQDjsgkFzbH8tIDXWemvEkWrHZ7eY4EsBsAbnIk35gX58OlPLe WKRGwCo8gh7Oi8DorVLYOxdqsRfMguMIsC7yzdqzQe2M1jjFPRMkGscLr4oq6SDw fE1Us+0JZweVcWYz+XBKtkfQqr5jgrCJ/69wpc3h6LbOxJhrAyU57Mq+No3DYlRy /NPmfQpOpzZliyVutBovdC20iPaGG4pDFsRCoruM+si7HWPnxkKdBttr+PoXD5GT 5Twk49nFVJnP8WUrhmpg4/nG2AToH7byKuQpsA8XwgaewBCdB12Gg32df8IBC7CW GffwsTGvyY+QYEllWVHB =afz2 -----END PGP SIGNATURE-----