From stpeter@stpeter.im Tue Oct 18 10:33:50 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 50EC821F8C04 for ; Tue, 18 Oct 2011 10:33:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.818 X-Spam-Level: X-Spam-Status: No, score=-102.818 tagged_above=-999 required=5 tests=[AWL=-0.219, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NqPSnQK1sM-j for ; Tue, 18 Oct 2011 10:33:49 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id BD6A821F8BE9 for ; Tue, 18 Oct 2011 10:33:49 -0700 (PDT) Received: from dhcp-64-101-72-193.cisco.com (unknown [64.101.72.193]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id BF3FB41E49 for ; Tue, 18 Oct 2011 11:38:42 -0600 (MDT) Message-ID: <4E9DB87B.6090004@stpeter.im> Date: Tue, 18 Oct 2011 11:33:47 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: precis@ietf.org X-Enigmail-Version: 1.3.2 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [precis] do we need both SecretClass and FreeClass? 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, 18 Oct 2011 17:33:50 -0000 As previously mentioned, I posted to the saag@ietf.org list requesting input on internationalized passwords... http://www.ietf.org/mail-archive/web/saag/current/msg03476.html Yaron Sheffer asked: "how can you disallow space characters (presumably including ASCII SPACE) from the Secret Class?" If we say that spaces are valid in the SecretClass, then there is no difference between the SecretClass and the FreeClass. That might be a fine outcome (fewer classes to define and implement), but I wanted to check with the WG before making that change in the framework spec. Thanks! Peter -- Peter Saint-Andre https://stpeter.im/ From mamille2@cisco.com Tue Oct 18 10:39:45 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 5834221F8C45 for ; Tue, 18 Oct 2011 10:39:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MnA3AqoRE-yZ for ; Tue, 18 Oct 2011 10:39:44 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id A15D821F8C44 for ; Tue, 18 Oct 2011 10:39:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mamille2@cisco.com; l=4342; q=dns/txt; s=iport; t=1318959584; x=1320169184; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=oXCa4A23uHIlq7AFXJrt8i6YE2deNVb5xKEmsVcZN8o=; b=i/AWvgJzg7dNbU/5lYmEEC3iwIlZSPLT729Qd9Aqnef0C7UCCRH+h/aM w6ZGklUsbExSDm5b3o4zAznHuzuLHSnYRlwbcdlOiMJbcuBOPpZbkTnJx i3b0U6+hF6uJGVgv7kFPwZG+Uemlg9qn3dmjIvI8CVqGYB441TgV/dkjj Q=; X-Files: smime.p7s : 2214 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAGG5nU6rRDoI/2dsb2JhbABEpjyCMoEFgW4BAQEDARIBZgULC0YCVQYTCRmHXgiYFgGeboJPhGthBIgCi3uKMIdF X-IronPort-AV: E=Sophos;i="4.69,366,1315180800"; d="p7s'?scan'208";a="8626270" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 18 Oct 2011 17:39:37 +0000 Received: from dhcp-64-101-72-216.cisco.com (dhcp-64-101-72-216.cisco.com [64.101.72.216]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p9IHdatp021282; Tue, 18 Oct 2011 17:39:36 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-16--797514146; protocol="application/pkcs7-signature"; micalg=sha1 From: Matt Miller In-Reply-To: <4E9DB87B.6090004@stpeter.im> Date: Tue, 18 Oct 2011 11:39:45 -0600 Message-Id: References: <4E9DB87B.6090004@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1084) Cc: precis@ietf.org Subject: Re: [precis] do we need both SecretClass and FreeClass? 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, 18 Oct 2011 17:39:45 -0000 --Apple-Mail-16--797514146 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 18, 2011, at 11:33, Peter Saint-Andre wrote: > As previously mentioned, I posted to the saag@ietf.org list requesting > input on internationalized passwords... >=20 > http://www.ietf.org/mail-archive/web/saag/current/msg03476.html >=20 > Yaron Sheffer asked: "how can you disallow space characters = (presumably > including ASCII SPACE) from the Secret Class?" >=20 > If we say that spaces are valid in the SecretClass, then there is no > difference between the SecretClass and the FreeClass. That might be a > fine outcome (fewer classes to define and implement), but I wanted to > check with the WG before making that change in the framework spec. >=20 > Thanks! >=20 > Peter I think allowing spaces is worthwhile; more entropy, and it's something = that just about every input device supports. Also, this (-: - m&m Matt Miller - Collaboration Software Group - Cisco Systems, Inc. --Apple-Mail-16--797514146 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFNTCCBTEw ggMZoAMCAQICAwmYMjANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEyMTQxNzQ3MTlaFw0x MjEyMTMxNzQ3MTlaMDwxFzAVBgNVBAMTDk1hdHRoZXcgTWlsbGVyMSEwHwYJKoZIhvcNAQkBFhJt YW1pbGxlMkBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC7Sh5cQYtd /kfoG3KjXd8i2esxt+BtHCmuiSku2VECC6msLKzA08cGJ31GfyX7+996TV3D5omh51j5fznfFikk cVGsuKe+omo70Aidw48ISGygQk8ZJrU8JVVfTjKVJRX39wgj8w8CI/BCz4kXLirIBWKTv1ARuqsO 7I1aqT7pWHAwlAKIbYYEwfz46OjyzmqknglOecy/1PR09nXwAAIepSo0Jk9edqsU8Pdqsbx8cPUV jlFtVkk+58ORjefl+4BoGrzW24rGG2B04sNPrycNqZEaJLmdk5J9ie/FMV10H8wFW8syomuacPxv NhoUgNnkYsJiO7zJEKUUmbmW1GPFAgMBAAGjgf4wgfswDAYDVR0TAQH/BAIwADBWBglghkgBhvhC AQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBo dHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEE AYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzAB hhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMB0GA1UdEQQWMBSBEm1hbWlsbGUyQGNpc2NvLmNvbTAN BgkqhkiG9w0BAQUFAAOCAgEAoa/WVlTWG/rbVIFlG1tCdJrbVvIWNfUNSgojunKsoaVGCoIh7T1+ SgWe8sV+r7s5bVlq66iGxTm/qoKMHM9i4aNGlwWDkXqLHoCKbY4qKPGKnn7PaoA6DWQ5u7ZKBkn9 N2fY8iLxiAy/hLnjtRLlbSr2yBX0DbO1K0ORLDwfO2MUf1j2Cou+qVvEmyEe7cUq37iOOsNbtghT xjn+RE7WJiHcR9deAkfI1xXi7UZcFME+k6nhdnX/qWFFLox0fJJCzX1H8DTzRIjA+ciNLWSG+TRx s7fAn+YZisJdkGxMcWlHZxSu+ybPjc9T7zCyf4+yFHigdOMNxiQ2k/E9WTJ84xIis2TG3E9Nba9B PMb6cgjiqGxiFpKKHj9/5A3wDIHZ8dof+M7YFGnHzwF9i72ZEoaO3hMEhAg9LhqGtQtEZohbTZL2 FOeT+8VjUHSOKhEYurQjWrHDj+ZyDjzhOE/KMwqSWokZhoy0s+VQ05BrVlbXd5DJaB/Hem0MdDUc /6IjqtI6f8O/HLQFAVUQgtW50bfCjDOAB/SaEKzygblcAHxSKDbduRQaRst6cIHEy4eQxvxrHIhg b2KWZ00jS+7NUnAMOyzIJTcZfV5mkCb8UjMHq9NSChwpBFuDzpXxjU20xJGDvbVWNDwfbITCczph p4uuhLITzvhHKaUNwxoqx0oxggMzMIIDLwIBATCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYD VQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRo b3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDCZgyMAkGBSsOAwIaBQCg ggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMTAxODE3Mzk0 NlowIwYJKoZIhvcNAQkEMRYEFNHp6GCXv/RDnE99jeY0vnsXQiu9MIGRBgkrBgEEAYI3EAQxgYMw gYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIw IAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0 QGNhY2VydC5vcmcCAwmYMjCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4GA1UEChMHUm9vdCBD QTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25p bmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwmYMjANBgkq hkiG9w0BAQEFAASCAQBTmjDDttNVvorbBpgyuY4Bo3vVLxErYlecL6cUx1BzOng6FDKpSDJfJfvV 7i1cd+thdxteLRJxQppVE9AQ3LUtTAvQpWqTIIcuB6lu2SvUYPmT6zURkofFbpXXyCP9/kOnXnFS 0YxuThelAS0tboPx6F5HnFCMxW02NXutvORYXk0H9JQBCDKhl3h9d3JkREPrAt4A405dZtAQhB3T TsoCq0oUoSbnmXxbrKFwTIfD9LBALR5P5UdpYnweF2Wseeb2m/fGkP5cHozLEToCrGWIw3CNrM72 VV+iraNaXq2/6UglpiYOb9r2ggQwElDaXkxyVRNdu2c1sf/AUZorsrxkAAAAAAAA --Apple-Mail-16--797514146-- From stpeter@stpeter.im Tue Oct 18 10:53:45 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 5CAD721F8C69 for ; Tue, 18 Oct 2011 10:53:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.786 X-Spam-Level: X-Spam-Status: No, score=-102.786 tagged_above=-999 required=5 tests=[AWL=-0.187, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b0tHdEvMWbzU for ; Tue, 18 Oct 2011 10:53:45 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id F1AF121F8C68 for ; Tue, 18 Oct 2011 10:53:44 -0700 (PDT) Received: from dhcp-64-101-72-193.cisco.com (unknown [64.101.72.193]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 0BD4541E49 for ; Tue, 18 Oct 2011 11:58:37 -0600 (MDT) Message-ID: <4E9DBD27.8050600@stpeter.im> Date: Tue, 18 Oct 2011 11:53:43 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: precis@ietf.org X-Enigmail-Version: 1.3.2 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [precis] passwords as octet strings 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, 18 Oct 2011 17:53:45 -0000 On the SAAG list, Mike Parker expressed concerns about mandating that passwords MUST be Unicode, because some systems store passwords as octet strings... http://www.ietf.org/mail-archive/web/saag/current/msg03479.html As I see it, the PRECIS WG is not mandating, and could not mandate, that any given application technology MUST support non-ASCII passwords. Instead, it's giving protocol designers a common tool for preparing and comparing passwords (and other strings) containing Unicode characters, if they choose to support such things. However, we might want to provide some text in the security considerations about the desirability (or not) of full-Unicode passwords. Peter -- Peter Saint-Andre https://stpeter.im/ From ajs@anvilwalrusden.com Tue Oct 18 11:12:04 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 6E2EE21F8C1B for ; Tue, 18 Oct 2011 11:12:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.397 X-Spam-Level: X-Spam-Status: No, score=-2.397 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wTDfVAUw2Zl9 for ; Tue, 18 Oct 2011 11:12:03 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id D3B4921F8BAD for ; Tue, 18 Oct 2011 11:12:03 -0700 (PDT) Received: from shinkuro.com (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 369BF1ECB41D for ; Tue, 18 Oct 2011 18:11:53 +0000 (UTC) Date: Tue, 18 Oct 2011 14:11:59 -0400 From: Andrew Sullivan To: precis@ietf.org Message-ID: <20111018181159.GG13166@shinkuro.com> References: <4E9DBD27.8050600@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E9DBD27.8050600@stpeter.im> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [precis] passwords as octet strings 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, 18 Oct 2011 18:12:04 -0000 On Tue, Oct 18, 2011 at 11:53:43AM -0600, Peter Saint-Andre wrote: > On the SAAG list, Mike Parker expressed concerns about mandating that > passwords MUST be Unicode, because some systems store passwords as octet > strings... Right. Precis can hardly dictate what programs not implementing its specifications do, any more than precis can go back in time and cause applications to do this. (Compare this with the IDNA2008 MUSTs: every non-compliant fake A-label is still a perfectly good DNS label. Indeed, the string "can't" is not a legal IDNA2008 label, but it's a valid DNS label anyway.) > Instead, it's giving protocol designers a common tool for preparing and > comparing passwords (and other strings) containing Unicode characters, > if they choose to support such things. Exactly: if you want to do precis, then it MUST be Unicode. Behaviour for strings that are not Unicode, including binary blobs and any other character encoding, is undefined. > However, we might want to provide some text in the security > considerations about the desirability (or not) of full-Unicode passwords. I'm slow, but what's the security consideration? There are interoperability considerations: if two applications want to co-operate in authentication, then they're going to need to use Unicode or make up their own protocol. A -- Andrew Sullivan ajs@anvilwalrusden.com From stpeter@stpeter.im Tue Oct 18 11:15:33 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 47A2D21F8BCB for ; Tue, 18 Oct 2011 11:15:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.774 X-Spam-Level: X-Spam-Status: No, score=-102.774 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CCRzob6jLmwH for ; Tue, 18 Oct 2011 11:15:32 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id BC9DD21F8B92 for ; Tue, 18 Oct 2011 11:15:32 -0700 (PDT) Received: from dhcp-64-101-72-193.cisco.com (unknown [64.101.72.193]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id C4D8B41E49; Tue, 18 Oct 2011 12:20:25 -0600 (MDT) Message-ID: <4E9DC243.4040803@stpeter.im> Date: Tue, 18 Oct 2011 12:15:31 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Andrew Sullivan References: <4E9DBD27.8050600@stpeter.im> <20111018181159.GG13166@shinkuro.com> In-Reply-To: <20111018181159.GG13166@shinkuro.com> X-Enigmail-Version: 1.3.2 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: precis@ietf.org Subject: Re: [precis] passwords as octet strings 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, 18 Oct 2011 18:15:33 -0000 On 10/18/11 12:11 PM, Andrew Sullivan wrote: > On Tue, Oct 18, 2011 at 11:53:43AM -0600, Peter Saint-Andre wrote: >> On the SAAG list, Mike Parker expressed concerns about mandating that >> passwords MUST be Unicode, because some systems store passwords as octet >> strings... > > Right. Precis can hardly dictate what programs not implementing its > specifications do, any more than precis can go back in time and cause > applications to do this. (Compare this with the IDNA2008 MUSTs: every > non-compliant fake A-label is still a perfectly good DNS label. > Indeed, the string "can't" is not a legal IDNA2008 label, but it's a > valid DNS label anyway.) > >> Instead, it's giving protocol designers a common tool for preparing and >> comparing passwords (and other strings) containing Unicode characters, >> if they choose to support such things. > > Exactly: if you want to do precis, then it MUST be Unicode. Behaviour > for strings that are not Unicode, including binary blobs and any other > character encoding, is undefined. Agreed with all that. >> However, we might want to provide some text in the security >> considerations about the desirability (or not) of full-Unicode passwords. > > I'm slow, but what's the security consideration? There are > interoperability considerations: if two applications want to > co-operate in authentication, then they're going to need to use > Unicode or make up their own protocol. Right, it's text about interoperability. Where exactly that belongs is another matter. I'm happy to add a section about interoperability. Peter -- Peter Saint-Andre https://stpeter.im/ From patrik@frobbit.se Tue Oct 18 12:20: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 A781B21F8D77 for ; Tue, 18 Oct 2011 12:20:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id miW5+eKYG6Hh for ; Tue, 18 Oct 2011 12:20:06 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id E192421F8D76 for ; Tue, 18 Oct 2011 12:20:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 8E589122FE818; Tue, 18 Oct 2011 21:20:04 +0200 (CEST) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BrPSOJ1t4Tia; Tue, 18 Oct 2011 21:20:03 +0200 (CEST) Received: from [IPv6:2a02:80:3ffc::14] (unknown [IPv6:2a02:80:3ffc::14]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id 32EF9122FE810; Tue, 18 Oct 2011 21:20:03 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <4E9DC243.4040803@stpeter.im> Date: Tue, 18 Oct 2011 21:20:02 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <11733D0D-0C58-4415-BE7B-40EC025E0B49@frobbit.se> References: <4E9DBD27.8050600@stpeter.im> <20111018181159.GG13166@shinkuro.com> <4E9DC243.4040803@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1251.1) Cc: precis@ietf.org Subject: Re: [precis] passwords as octet strings 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, 18 Oct 2011 19:20:06 -0000 On 18 okt 2011, at 20:15, Peter Saint-Andre wrote: >>> However, we might want to provide some text in the security >>> considerations about the desirability (or not) of full-Unicode = passwords. >>=20 >> I'm slow, but what's the security consideration? There are >> interoperability considerations: if two applications want to >> co-operate in authentication, then they're going to need to use >> Unicode or make up their own protocol. =20 >=20 > Right, it's text about interoperability. Where exactly that belongs is > another matter. I'm happy to add a section about interoperability. Please separate the question on what charset (including encoding) is = used in the protocol with how comparisons (etc) is done. What is the = responsibility on the "client" and "server", etc. Patrik From aland@deployingradius.com Tue Oct 18 12:29:58 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 B3D3A21F8D29 for ; Tue, 18 Oct 2011 12:29:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GjlrVbx7xW4n for ; Tue, 18 Oct 2011 12:29:58 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 3E38D21F8D07 for ; Tue, 18 Oct 2011 12:29:58 -0700 (PDT) Message-ID: <4E9DD39B.4020802@deployingradius.com> Date: Tue, 18 Oct 2011 21:29:31 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Peter Saint-Andre References: <4E9DB87B.6090004@stpeter.im> In-Reply-To: <4E9DB87B.6090004@stpeter.im> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: precis@ietf.org Subject: Re: [precis] do we need both SecretClass and FreeClass? 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, 18 Oct 2011 19:29:58 -0000 Peter Saint-Andre wrote: > Yaron Sheffer asked: "how can you disallow space characters (presumably > including ASCII SPACE) from the Secret Class?" I had wondered the same thing... > If we say that spaces are valid in the SecretClass, then there is no > difference between the SecretClass and the FreeClass. That might be a > fine outcome (fewer classes to define and implement), but I wanted to > check with the WG before making that change in the framework spec. I'm familiar with many systems I'm that allow spaces in passwords, and others that don't. It's really too hard to say which is the best choice. Alan DeKok. From dthaler@microsoft.com Wed Oct 19 15:56:38 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 B5E0111E80B3 for ; Wed, 19 Oct 2011 15:56:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.532 X-Spam-Level: X-Spam-Status: No, score=-110.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id InhlJaaaRpsK for ; Wed, 19 Oct 2011 15:56:38 -0700 (PDT) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 2382911E808A for ; Wed, 19 Oct 2011 15:56:37 -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; Wed, 19 Oct 2011 15:56:37 -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.339.2; Wed, 19 Oct 2011 15:56:37 -0700 Received: from TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.90]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.01.0339.002; Wed, 19 Oct 2011 15:56:37 -0700 From: Dave Thaler To: Peter Saint-Andre , "precis@ietf.org" Thread-Topic: [precis] do we need both SecretClass and FreeClass? Thread-Index: AQHMjbwybyIGYLNfQEeqk/Al92CAm5WESNVw Date: Wed, 19 Oct 2011 22:56:36 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B29D991@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> References: <4E9DB87B.6090004@stpeter.im> In-Reply-To: <4E9DB87B.6090004@stpeter.im> 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 Subject: Re: [precis] do we need both SecretClass and FreeClass? 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, 19 Oct 2011 22:56:38 -0000 That sounds right to me. -Dave -----Original Message----- From: precis-bounces@ietf.org [mailto:precis-bounces@ietf.org] On Behalf Of= Peter Saint-Andre Sent: Tuesday, October 18, 2011 10:34 AM To: precis@ietf.org Subject: [precis] do we need both SecretClass and FreeClass? As previously mentioned, I posted to the saag@ietf.org list requesting inpu= t on internationalized passwords... http://www.ietf.org/mail-archive/web/saag/current/msg03476.html Yaron Sheffer asked: "how can you disallow space characters (presumably inc= luding ASCII SPACE) from the Secret Class?" If we say that spaces are valid in the SecretClass, then there is no differ= ence between the SecretClass and the FreeClass. That might be a fine outcom= e (fewer classes to define and implement), but I wanted to check with the W= G before making that change in the framework spec. Thanks! Peter -- Peter Saint-Andre https://stpeter.im/ _______________________________________________ precis mailing list precis@ietf.org https://www.ietf.org/mailman/listinfo/precis From dthaler@microsoft.com Wed Oct 19 16:03: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 A47C021F8B3A for ; Wed, 19 Oct 2011 16:03:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.539 X-Spam-Level: X-Spam-Status: No, score=-110.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id md6x0UQO4VD6 for ; Wed, 19 Oct 2011 16:03:11 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 345A521F8B34 for ; Wed, 19 Oct 2011 16:03:11 -0700 (PDT) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 19 Oct 2011 16:03:11 -0700 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) with Microsoft SMTP Server (TLS) id 14.1.339.2; Wed, 19 Oct 2011 16:03:11 -0700 Received: from TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.90]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.01.0339.002; Wed, 19 Oct 2011 16:03:10 -0700 From: Dave Thaler To: "precis@ietf.org" Thread-Topic: Should we define any subclasses of NameClass? Thread-Index: AcyOsrC72vuTkOfaSqStbzUfIegPQg== Date: Wed, 19 Oct 2011 23:03:09 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B29D9BD@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.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 Subject: [precis] Should we define any subclasses of NameClass? 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, 19 Oct 2011 23:03:11 -0000 Currently NameClass is pretty generic. I'm wondering whether it would make= sense to define any more complex concepts/subclasses. For example DomainNameClass might be a subclass with a specific set of defa= ult values of Valid, Disallowed, Case Mapping, etc. We might also define the concept of a ComplexClass, which would mean that t= he string has some internal structure (e.g., delimiter) where each portion might naturall= y map to another class (SecretClass, NameClass, or whatever). For example an email address= is a ComplexClass, which is itself composed of two pieces with different classes (left side an= d right side of @). Useful or not useful? -Dave From yoshiro.yoneya@jprs.co.jp Thu Oct 20 02:32: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 1E06A21F8B08 for ; Thu, 20 Oct 2011 02:32:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.09 X-Spam-Level: X-Spam-Status: No, score=-100.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BnCwSwextZG6 for ; Thu, 20 Oct 2011 02:32:34 -0700 (PDT) Received: from send11.jprs.co.jp (send11.jprs.co.jp [IPv6:2001:df0:8:6::62]) by ietfa.amsl.com (Postfix) with ESMTP id 65C7621F8AF9 for ; Thu, 20 Oct 2011 02:32:34 -0700 (PDT) Received: from sendsms11.jprs.co.jp (sendsms11.jprs.co.jp [202.11.17.111]) by send11.jprs.co.jp (8.13.8+Sun/8.13.8) with ESMTP id p9K9WXV8020289 for ; Thu, 20 Oct 2011 18:32:33 +0900 (JST) Received: from sendsms11.jprs.co.jp (unknown [127.0.0.1]) by sendsms11.jprs.co.jp (Symantec Mail Security) with ESMTP id EA1ED382F for ; Thu, 20 Oct 2011 18:32:32 +0900 (JST) X-AuditID: ca0b116f-0000000a00002865-32-4e9feab00f97 Received: from NOTE550 (off-cpu04.tyo.jprs.co.jp [172.18.4.14]) by sendsms11.jprs.co.jp (Symantec Mail Security) with SMTP id A4DD6382E for ; Thu, 20 Oct 2011 18:32:32 +0900 (JST) Date: Thu, 20 Oct 2011 18:32:30 +0900 From: Yoshiro YONEYA To: precis@ietf.org Message-Id: <20111020183230.ba042696.yoshiro.yoneya@jprs.co.jp> X-Mailer: Sylpheed 3.1.2 (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] IETF82 Taipei 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: Thu, 20 Oct 2011 09:32:35 -0000 Dear all, Following is draft agenda for IETF 82 Taipei. Please send comments/additions/changes to the chairs. 1. Administrativia 2. WG I-Ds 2.1 Problem-statement 2.2 Framework 3. Discussion 3.1 Internationalized passwords 3.2 Mappings other than case 4. Next steps Marc & Yoneya, co-chairs -- Yoshiro YONEYA From marc.blanchet@viagenie.ca Thu Oct 20 03:49:10 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 7E04021F8AD9 for ; Thu, 20 Oct 2011 03:49:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.605 X-Spam-Level: X-Spam-Status: No, score=-101.605 tagged_above=-999 required=5 tests=[AWL=0.994, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yy5IjlSYQTn6 for ; Thu, 20 Oct 2011 03:49:08 -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 812CD21F8AD3 for ; Thu, 20 Oct 2011 03:49:08 -0700 (PDT) Received: from [10.104.70.77] (unknown [75.98.19.132]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 860C721B94; Thu, 20 Oct 2011 06:49:02 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Marc Blanchet In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B29D9BD@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Date: Thu, 20 Oct 2011 06:49:00 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9B57C850BB53634CACEC56EF4853FF653B29D9BD@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> To: Dave Thaler X-Mailer: Apple Mail (2.1251.1) Cc: "precis@ietf.org" Subject: Re: [precis] Should we define any subclasses of NameClass? 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, 20 Oct 2011 10:49:10 -0000 maybe useful, but I think we should do the "least" amount of classes, = criteria being that at least one protocol is using it. This would be for = the framework document. Obviously, a protocol can define a sub-class or = else. So if we see right now a protocol that would be using a new class, = I think it is a good idea to put it in the framework, otherwise leave = it. Marc. Le 2011-10-19 =E0 19:03, Dave Thaler a =E9crit : > Currently NameClass is pretty generic. I'm wondering whether it would = make sense to define any > more complex concepts/subclasses. >=20 > For example DomainNameClass might be a subclass with a specific set of = default > values of Valid, Disallowed, Case Mapping, etc. >=20 > We might also define the concept of a ComplexClass, which would mean = that the string has > some internal structure (e.g., delimiter) where each portion might = naturally map to another > class (SecretClass, NameClass, or whatever). For example an email = address is a ComplexClass, > which is itself composed of two pieces with different classes (left = side and right side of @). >=20 > Useful or not useful? >=20 > -Dave > _______________________________________________ > precis mailing list > precis@ietf.org > https://www.ietf.org/mailman/listinfo/precis From mamille2@cisco.com Thu Oct 20 08:24: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 4C4EB21F8C37 for ; Thu, 20 Oct 2011 08:24:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tA0CJLno7wNj for ; Thu, 20 Oct 2011 08:24:28 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 5469421F8C09 for ; Thu, 20 Oct 2011 08:24:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mamille2@cisco.com; l=5274; q=dns/txt; s=iport; t=1319124268; x=1320333868; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=nmYzUOJUqhlUharyE9SwM00gBLayH9UXWn55g5/IQkw=; b=Qk5y6JLYmCm4/WvyIYMtzZsyDA08FrqUKUjTQMAO/34s4KJvrkVRf7OK vJmjOuyNB0pEaiikfBkW45c16n1LTKJjxSYNNPGbIu9Wf/vBU8eUSivkP z35eZu8iqVE2Qz/qDg2z9JMpMnT8lqXUdFvA6JA75/3jaZQ9P4VHnFf5w c=; X-Files: smime.p7s : 2214 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFALA8oE6rRDoG/2dsb2JhbABDpleCQYEFgW4BAQEDAQEBAQ8BWwsFCwtGAiUwBhMih14Il04BnjUEh0hhBIgDi32Rdg X-IronPort-AV: E=Sophos;i="4.69,379,1315180800"; d="p7s'?scan'208";a="9159255" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 20 Oct 2011 15:24:28 +0000 Received: from dhcp-64-101-72-216.cisco.com (dhcp-64-101-72-216.cisco.com [64.101.72.216]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p9KFORoU022378; Thu, 20 Oct 2011 15:24:27 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-4--632820530; protocol="application/pkcs7-signature"; micalg=sha1 From: Matt Miller In-Reply-To: Date: Thu, 20 Oct 2011 09:24:39 -0600 Message-Id: References: <9B57C850BB53634CACEC56EF4853FF653B29D9BD@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> To: Marc Blanchet X-Mailer: Apple Mail (2.1084) Cc: "precis@ietf.org" Subject: Re: [precis] Should we define any subclasses of NameClass? 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, 20 Oct 2011 15:24:29 -0000 --Apple-Mail-4--632820530 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Personally, I think the bar for inclusion of classes ought to be higher = than one protocol, but I don't have a more definitive bar to set. The = DomainNameClass most likely exceeds my nebulous bar, but I think we = should get through the basics first. On Oct 20, 2011, at 04:49, Marc Blanchet wrote: > maybe useful, but I think we should do the "least" amount of classes, = criteria being that at least one protocol is using it. This would be for = the framework document. Obviously, a protocol can define a sub-class or = else. So if we see right now a protocol that would be using a new class, = I think it is a good idea to put it in the framework, otherwise leave = it. >=20 > Marc. >=20 > Le 2011-10-19 =E0 19:03, Dave Thaler a =E9crit : >=20 >> Currently NameClass is pretty generic. I'm wondering whether it = would make sense to define any >> more complex concepts/subclasses. >>=20 >> For example DomainNameClass might be a subclass with a specific set = of default >> values of Valid, Disallowed, Case Mapping, etc. >>=20 >> We might also define the concept of a ComplexClass, which would mean = that the string has >> some internal structure (e.g., delimiter) where each portion might = naturally map to another >> class (SecretClass, NameClass, or whatever). For example an email = address is a ComplexClass, >> which is itself composed of two pieces with different classes (left = side and right side of @). >>=20 >> Useful or not useful? >>=20 >> -Dave >> _______________________________________________ >> precis mailing list >> precis@ietf.org >> https://www.ietf.org/mailman/listinfo/precis >=20 > _______________________________________________ > precis mailing list > precis@ietf.org > https://www.ietf.org/mailman/listinfo/precis - m&m Matt Miller - Collaboration Software Group - Cisco Systems, Inc. --Apple-Mail-4--632820530 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFNTCCBTEw ggMZoAMCAQICAwmYMjANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEyMTQxNzQ3MTlaFw0x MjEyMTMxNzQ3MTlaMDwxFzAVBgNVBAMTDk1hdHRoZXcgTWlsbGVyMSEwHwYJKoZIhvcNAQkBFhJt YW1pbGxlMkBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC7Sh5cQYtd /kfoG3KjXd8i2esxt+BtHCmuiSku2VECC6msLKzA08cGJ31GfyX7+996TV3D5omh51j5fznfFikk cVGsuKe+omo70Aidw48ISGygQk8ZJrU8JVVfTjKVJRX39wgj8w8CI/BCz4kXLirIBWKTv1ARuqsO 7I1aqT7pWHAwlAKIbYYEwfz46OjyzmqknglOecy/1PR09nXwAAIepSo0Jk9edqsU8Pdqsbx8cPUV jlFtVkk+58ORjefl+4BoGrzW24rGG2B04sNPrycNqZEaJLmdk5J9ie/FMV10H8wFW8syomuacPxv NhoUgNnkYsJiO7zJEKUUmbmW1GPFAgMBAAGjgf4wgfswDAYDVR0TAQH/BAIwADBWBglghkgBhvhC AQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBo dHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEE AYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzAB hhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMB0GA1UdEQQWMBSBEm1hbWlsbGUyQGNpc2NvLmNvbTAN BgkqhkiG9w0BAQUFAAOCAgEAoa/WVlTWG/rbVIFlG1tCdJrbVvIWNfUNSgojunKsoaVGCoIh7T1+ SgWe8sV+r7s5bVlq66iGxTm/qoKMHM9i4aNGlwWDkXqLHoCKbY4qKPGKnn7PaoA6DWQ5u7ZKBkn9 N2fY8iLxiAy/hLnjtRLlbSr2yBX0DbO1K0ORLDwfO2MUf1j2Cou+qVvEmyEe7cUq37iOOsNbtghT xjn+RE7WJiHcR9deAkfI1xXi7UZcFME+k6nhdnX/qWFFLox0fJJCzX1H8DTzRIjA+ciNLWSG+TRx s7fAn+YZisJdkGxMcWlHZxSu+ybPjc9T7zCyf4+yFHigdOMNxiQ2k/E9WTJ84xIis2TG3E9Nba9B PMb6cgjiqGxiFpKKHj9/5A3wDIHZ8dof+M7YFGnHzwF9i72ZEoaO3hMEhAg9LhqGtQtEZohbTZL2 FOeT+8VjUHSOKhEYurQjWrHDj+ZyDjzhOE/KMwqSWokZhoy0s+VQ05BrVlbXd5DJaB/Hem0MdDUc /6IjqtI6f8O/HLQFAVUQgtW50bfCjDOAB/SaEKzygblcAHxSKDbduRQaRst6cIHEy4eQxvxrHIhg b2KWZ00jS+7NUnAMOyzIJTcZfV5mkCb8UjMHq9NSChwpBFuDzpXxjU20xJGDvbVWNDwfbITCczph p4uuhLITzvhHKaUNwxoqx0oxggMzMIIDLwIBATCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYD VQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRo b3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDCZgyMAkGBSsOAwIaBQCg ggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMTAyMDE1MjQz OVowIwYJKoZIhvcNAQkEMRYEFJT+ZvlpNTmjyU/fd5oUiuWTwcRdMIGRBgkrBgEEAYI3EAQxgYMw gYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIw IAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0 QGNhY2VydC5vcmcCAwmYMjCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4GA1UEChMHUm9vdCBD QTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25p bmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwmYMjANBgkq hkiG9w0BAQEFAASCAQAW0LKc4sS4HGt+yFvY5NnowmMoitDHLUTE9nDEEHCXewHcTYv30yXO4Win 6o007+NxByLTYi+iuql/E4F3GAkrUkxqVNwA8QWZ8jCnbLk1BYMExE87dBSfivOScF3R7SIzYxxd p4XmnR0yX49l4IiAABdsfczXYFZNPZUQkTrkigZSzAFAbBkqHjvSCZbKDZ2w18uiiPAnSAK+KXNM Lb2IVyWaa1shpFbK1narGnQN2gR0X1R2GG+YcQHiCt8V32O39OzXYse7HMyFnW/zyhI4P/hjjHIM ZoIWR+fB0/H2dxi2uDH8tlorx+q08MRL5FS7QZfkVop5Nn9vVwNk9p1fAAAAAAAA --Apple-Mail-4--632820530-- From marc.blanchet@viagenie.ca Thu Oct 20 12:25:07 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 935561F0C4D for ; Thu, 20 Oct 2011 12:25:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6m62hAa5emzU for ; Thu, 20 Oct 2011 12:25:07 -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 177AC1F0C4A for ; Thu, 20 Oct 2011 12:25:07 -0700 (PDT) Received: from [172.20.10.2] (unknown [74.198.165.40]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 0BB6E20DC6; Thu, 20 Oct 2011 15:25:05 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Marc Blanchet In-Reply-To: Date: Thu, 20 Oct 2011 15:25:04 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3CF3F065-64D1-44D2-8039-A3C0DF84BE18@viagenie.ca> References: <9B57C850BB53634CACEC56EF4853FF653B29D9BD@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> To: Matt Miller X-Mailer: Apple Mail (2.1251.1) Cc: "precis@ietf.org" Subject: Re: [precis] Should we define any subclasses of NameClass? 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, 20 Oct 2011 19:25:07 -0000 Le 2011-10-20 =E0 11:24, Matt Miller a =E9crit : > Personally, I think the bar for inclusion of classes ought to be = higher than one protocol, maybe. but at least one... at the same time, if the bar is too high, we = will end up with not a framework useful, but a too small set that would = have a lot of profiles that changes the basic set. So there is a = balance. Marc. > but I don't have a more definitive bar to set. The DomainNameClass = most likely exceeds my nebulous bar, but I think we should get through = the basics first. >=20 >=20 > On Oct 20, 2011, at 04:49, Marc Blanchet wrote: >=20 >> maybe useful, but I think we should do the "least" amount of classes, = criteria being that at least one protocol is using it. This would be for = the framework document. Obviously, a protocol can define a sub-class or = else. So if we see right now a protocol that would be using a new class, = I think it is a good idea to put it in the framework, otherwise leave = it. >>=20 >> Marc. >>=20 >> Le 2011-10-19 =E0 19:03, Dave Thaler a =E9crit : >>=20 >>> Currently NameClass is pretty generic. I'm wondering whether it = would make sense to define any >>> more complex concepts/subclasses. >>>=20 >>> For example DomainNameClass might be a subclass with a specific set = of default >>> values of Valid, Disallowed, Case Mapping, etc. >>>=20 >>> We might also define the concept of a ComplexClass, which would mean = that the string has >>> some internal structure (e.g., delimiter) where each portion might = naturally map to another >>> class (SecretClass, NameClass, or whatever). For example an email = address is a ComplexClass, >>> which is itself composed of two pieces with different classes (left = side and right side of @). >>>=20 >>> Useful or not useful? >>>=20 >>> -Dave >>> _______________________________________________ >>> precis mailing list >>> precis@ietf.org >>> https://www.ietf.org/mailman/listinfo/precis >>=20 >> _______________________________________________ >> precis mailing list >> precis@ietf.org >> https://www.ietf.org/mailman/listinfo/precis >=20 > - m&m >=20 > Matt Miller - > Collaboration Software Group - Cisco Systems, Inc. >=20 From jefsey@jefsey.com Fri Oct 21 03:30:37 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 E927F21F8B66 for ; Fri, 21 Oct 2011 03:30:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.633 X-Spam-Level: X-Spam-Status: No, score=-101.633 tagged_above=-999 required=5 tests=[AWL=0.967, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iKNw869WqS0n for ; Fri, 21 Oct 2011 03:30:37 -0700 (PDT) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by ietfa.amsl.com (Postfix) with ESMTP id 5F00021F8B64 for ; Fri, 21 Oct 2011 03:30:37 -0700 (PDT) Received: from 157.111-227-89.dsl.completel.net ([89.227.111.157]:63062 helo=jfcmsc.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1RHCMz-0001oi-2k; Fri, 21 Oct 2011 03:30:33 -0700 Message-Id: <7.0.1.0.2.20111021122557.06fb4778@jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 21 Oct 2011 12:36:57 +0200 To: Marc Blanchet , Dave Thaler From: JFC Morfin In-Reply-To: References: <9B57C850BB53634CACEC56EF4853FF653B29D9BD@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> 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" Subject: Re: [precis] Should we define any subclasses of NameClass? 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, 21 Oct 2011 10:30:38 -0000 At 12:49 20/10/2011, Marc Blanchet wrote: >maybe useful, but I think we should do the "least" amount of >classes, criteria being that at least one protocol is using it. This >would be for the framework document. Obviously, a protocol can >define a sub-class or else. So if we see right now a protocol that >would be using a new class, I think it is a good idea to put it in >the framework, otherwise leave it. > >Marc. I wonder if classes should be individually defined or if only the class concept would be enough at this stage. What could be defined are more precise criteria (e.g. accept spaces or not, accept upper cases or not, etc.). Classes would then be criteria containers. Then a mnemonic system could be defined to abbreviate a list of criteria into a name. This would be something similar to owner or mode in Unix. We could even consider the chclass command concept. jfc >Le 2011-10-19 ŕ 19:03, Dave Thaler a écrit : > > > Currently NameClass is pretty generic. I'm wondering whether it > would make sense to define any > > more complex concepts/subclasses. > > > > For example DomainNameClass might be a subclass with a specific > set of default > > values of Valid, Disallowed, Case Mapping, etc. > > > > We might also define the concept of a ComplexClass, which would > mean that the string has > > some internal structure (e.g., delimiter) where each portion > might naturally map to another > > class (SecretClass, NameClass, or whatever). For example an > email address is a ComplexClass, > > which is itself composed of two pieces with different classes > (left side and right side of @). > > > > Useful or not useful? > > > > -Dave > > _______________________________________________ > > precis mailing list > > precis@ietf.org > > https://www.ietf.org/mailman/listinfo/precis > >_______________________________________________ >precis mailing list >precis@ietf.org >https://www.ietf.org/mailman/listinfo/precis From mamille2@cisco.com Fri Oct 21 06:37: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 B31DA21F8C12 for ; Fri, 21 Oct 2011 06:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vgBbX0AXV0rR for ; Fri, 21 Oct 2011 06:37:02 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id E835D21F8C11 for ; Fri, 21 Oct 2011 06:37:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mamille2@cisco.com; l=6106; q=dns/txt; s=iport; t=1319204221; x=1320413821; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=Kl6bcppSHcctaJnZNTAVt+3YfyEEMjoVVgM8MfOthmo=; b=VLiI2lY094Z38dxHJ5ma7GbcpmZVpFUewGvaciEiF5JZ7QInznwS/KwF NQL1dghJvz+d6Cd3co/9qFSbYLQAjeHSzgXvt33ADb7uLqCtY5kvVTb9s j8TuGkXnEAetzKakLZTWklGCmFhfV/TmP3m6k9GLrJ/IRzsIf4DRHGrRX c=; X-Files: smime.p7s : 2214 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8FALZ0oU6rRDoI/2dsb2JhbABDpluCQYEFgW4BAQEDAQEBAQsEAVIJCwULCxguAiUwBhMih14IlUcBnjkEh19hBIgDi36ReQ X-IronPort-AV: E=Sophos;i="4.69,385,1315180800"; d="p7s'?scan'208";a="9380278" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 21 Oct 2011 13:37:01 +0000 Received: from dhcp-64-101-72-216.cisco.com (dhcp-64-101-72-216.cisco.com [64.101.72.216]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p9LDb15L010343; Fri, 21 Oct 2011 13:37:01 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-9--552863200; protocol="application/pkcs7-signature"; micalg=sha1 From: Matt Miller In-Reply-To: <3CF3F065-64D1-44D2-8039-A3C0DF84BE18@viagenie.ca> Date: Fri, 21 Oct 2011 07:37:16 -0600 Message-Id: <22B5378C-8E2C-466B-A54E-CDF5A4B6C23A@cisco.com> References: <9B57C850BB53634CACEC56EF4853FF653B29D9BD@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <3CF3F065-64D1-44D2-8039-A3C0DF84BE18@viagenie.ca> To: Marc Blanchet X-Mailer: Apple Mail (2.1084) Cc: "precis@ietf.org" Subject: Re: [precis] Should we define any subclasses of NameClass? 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, 21 Oct 2011 13:37:02 -0000 --Apple-Mail-9--552863200 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Oct 20, 2011, at 13:25, Marc Blanchet wrote: > Le 2011-10-20 =E0 11:24, Matt Miller a =E9crit : >=20 >> Personally, I think the bar for inclusion of classes ought to be = higher than one protocol, >=20 > maybe. but at least one... at the same time, if the bar is too high, = we will end up with not a framework useful, but a too small set that = would have a lot of profiles that changes the basic set. So there is a = balance. >=20 I totally agree there's a balance that needs to be struck, and a = criterion is "necessary for at least one protocol". My main point is that I think we should get consensus on what we have in = front of us first, then look at subclasses. - m&m Matt Miller - Collaboration Software Group - Cisco Systems, Inc. > Marc. >=20 >> but I don't have a more definitive bar to set. The DomainNameClass = most likely exceeds my nebulous bar, but I think we should get through = the basics first. >>=20 >>=20 >> On Oct 20, 2011, at 04:49, Marc Blanchet wrote: >>=20 >>> maybe useful, but I think we should do the "least" amount of = classes, criteria being that at least one protocol is using it. This = would be for the framework document. Obviously, a protocol can define a = sub-class or else. So if we see right now a protocol that would be using = a new class, I think it is a good idea to put it in the framework, = otherwise leave it. >>>=20 >>> Marc. >>>=20 >>> Le 2011-10-19 =E0 19:03, Dave Thaler a =E9crit : >>>=20 >>>> Currently NameClass is pretty generic. I'm wondering whether it = would make sense to define any >>>> more complex concepts/subclasses. >>>>=20 >>>> For example DomainNameClass might be a subclass with a specific set = of default >>>> values of Valid, Disallowed, Case Mapping, etc. >>>>=20 >>>> We might also define the concept of a ComplexClass, which would = mean that the string has >>>> some internal structure (e.g., delimiter) where each portion might = naturally map to another >>>> class (SecretClass, NameClass, or whatever). For example an email = address is a ComplexClass, >>>> which is itself composed of two pieces with different classes (left = side and right side of @). >>>>=20 >>>> Useful or not useful? >>>>=20 >>>> -Dave >>>> _______________________________________________ >>>> precis mailing list >>>> precis@ietf.org >>>> https://www.ietf.org/mailman/listinfo/precis >>>=20 >>> _______________________________________________ >>> precis mailing list >>> precis@ietf.org >>> https://www.ietf.org/mailman/listinfo/precis >>=20 >> - m&m >>=20 >> Matt Miller - >> Collaboration Software Group - Cisco Systems, Inc. >>=20 >=20 --Apple-Mail-9--552863200 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFNTCCBTEw ggMZoAMCAQICAwmYMjANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEyMTQxNzQ3MTlaFw0x MjEyMTMxNzQ3MTlaMDwxFzAVBgNVBAMTDk1hdHRoZXcgTWlsbGVyMSEwHwYJKoZIhvcNAQkBFhJt YW1pbGxlMkBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC7Sh5cQYtd /kfoG3KjXd8i2esxt+BtHCmuiSku2VECC6msLKzA08cGJ31GfyX7+996TV3D5omh51j5fznfFikk cVGsuKe+omo70Aidw48ISGygQk8ZJrU8JVVfTjKVJRX39wgj8w8CI/BCz4kXLirIBWKTv1ARuqsO 7I1aqT7pWHAwlAKIbYYEwfz46OjyzmqknglOecy/1PR09nXwAAIepSo0Jk9edqsU8Pdqsbx8cPUV jlFtVkk+58ORjefl+4BoGrzW24rGG2B04sNPrycNqZEaJLmdk5J9ie/FMV10H8wFW8syomuacPxv NhoUgNnkYsJiO7zJEKUUmbmW1GPFAgMBAAGjgf4wgfswDAYDVR0TAQH/BAIwADBWBglghkgBhvhC AQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBo dHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEE AYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzAB hhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMB0GA1UdEQQWMBSBEm1hbWlsbGUyQGNpc2NvLmNvbTAN BgkqhkiG9w0BAQUFAAOCAgEAoa/WVlTWG/rbVIFlG1tCdJrbVvIWNfUNSgojunKsoaVGCoIh7T1+ SgWe8sV+r7s5bVlq66iGxTm/qoKMHM9i4aNGlwWDkXqLHoCKbY4qKPGKnn7PaoA6DWQ5u7ZKBkn9 N2fY8iLxiAy/hLnjtRLlbSr2yBX0DbO1K0ORLDwfO2MUf1j2Cou+qVvEmyEe7cUq37iOOsNbtghT xjn+RE7WJiHcR9deAkfI1xXi7UZcFME+k6nhdnX/qWFFLox0fJJCzX1H8DTzRIjA+ciNLWSG+TRx s7fAn+YZisJdkGxMcWlHZxSu+ybPjc9T7zCyf4+yFHigdOMNxiQ2k/E9WTJ84xIis2TG3E9Nba9B PMb6cgjiqGxiFpKKHj9/5A3wDIHZ8dof+M7YFGnHzwF9i72ZEoaO3hMEhAg9LhqGtQtEZohbTZL2 FOeT+8VjUHSOKhEYurQjWrHDj+ZyDjzhOE/KMwqSWokZhoy0s+VQ05BrVlbXd5DJaB/Hem0MdDUc /6IjqtI6f8O/HLQFAVUQgtW50bfCjDOAB/SaEKzygblcAHxSKDbduRQaRst6cIHEy4eQxvxrHIhg b2KWZ00jS+7NUnAMOyzIJTcZfV5mkCb8UjMHq9NSChwpBFuDzpXxjU20xJGDvbVWNDwfbITCczph p4uuhLITzvhHKaUNwxoqx0oxggMzMIIDLwIBATCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYD VQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRo b3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDCZgyMAkGBSsOAwIaBQCg ggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMTAyMTEzMzcx N1owIwYJKoZIhvcNAQkEMRYEFN3va8Fuh5/L0RJc2ClX1kJvle8EMIGRBgkrBgEEAYI3EAQxgYMw gYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIw IAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0 QGNhY2VydC5vcmcCAwmYMjCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4GA1UEChMHUm9vdCBD QTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25p bmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwmYMjANBgkq hkiG9w0BAQEFAASCAQAjxgRdjB73mmRY4EcibmlRDG6woW970pKDidkP6TahQytJ4qDyyvRYmCky ziYQ6HgcZAfTkv9SO8FWbZ3XVNjLev4n9KiOLC53ITNIwRqrIzY3YtaVHZPpAwQ8wY2BKMDjSfwa pMlfncZvAsO0glPFEkCNwZFo8EaWwDIiODUMJsbhufrAGkddr5Uu4v7p7/E3gGS5EietQL0q62TF fZMyfno+66vZ8qx1vfuq0Jk6D+YmCUcPSJYDiSqhbwpwb96HD+VeNM+1XK3q6trYviZgyZlE4W+q VRVneB8C0C8XNsZYbZDaq/BIYVtRG7AF5o8M4GRNJhQLaNhNXaeHBbBoAAAAAAAA --Apple-Mail-9--552863200-- From yoshiro.yoneya@jprs.co.jp Tue Oct 25 22:50: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 79F7B21F8B2D for ; Tue, 25 Oct 2011 22:50:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.09 X-Spam-Level: X-Spam-Status: No, score=-100.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ihlCcNnPBtRV for ; Tue, 25 Oct 2011 22:50:29 -0700 (PDT) Received: from send11.jprs.co.jp (send11.jprs.co.jp [IPv6:2001:df0:8:6::62]) by ietfa.amsl.com (Postfix) with ESMTP id 792D021F8AF5 for ; Tue, 25 Oct 2011 22:50:26 -0700 (PDT) Received: from sendsms11.jprs.co.jp (sendsms11.jprs.co.jp [202.11.17.111]) by send11.jprs.co.jp (8.13.8+Sun/8.13.8) with ESMTP id p9Q5oPu5005832 for ; Wed, 26 Oct 2011 14:50:25 +0900 (JST) Received: from sendsms11.jprs.co.jp (unknown [127.0.0.1]) by sendsms11.jprs.co.jp (Symantec Mail Security) with ESMTP id 1794E3835 for ; Wed, 26 Oct 2011 14:50:25 +0900 (JST) X-AuditID: ca0b116f-0000000900002865-59-4ea79fa005bf Received: from NOTE550 (off-cpu04.tyo.jprs.co.jp [172.18.4.14]) by sendsms11.jprs.co.jp (Symantec Mail Security) with SMTP id 641F63834 for ; Wed, 26 Oct 2011 14:50:24 +0900 (JST) Date: Wed, 26 Oct 2011 14:50:17 +0900 From: Yoshiro YONEYA To: precis@ietf.org Message-Id: <20111026145017.35f865e5.yoshiro.yoneya@jprs.co.jp> X-Mailer: Sylpheed 3.1.2 (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] Fw: I-D Action: draft-yoneya-precis-mappings-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, 26 Oct 2011 05:50:30 -0000 Dear all, I submitted a preliminary mapping document as an individual (no hat). I'd like to discuss this topic at Taipei. -- Yoshiro YONEYA Begin forwarded message: Date: Mon, 24 Oct 2011 03:09:24 -0700 From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-yoneya-precis-mappings-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Mapping characters for PRECIS classes Author(s) : Yoshiro YONEYA Filename : draft-yoneya-precis-mappings-00.txt Pages : 9 Date : 2011-10-24 Preparation and comparison of internationalized strings ("PRECIS") Framework [I-D.ietf-precis-framework] is defining several classes of strings for preparation and comparison. In the document, case mapping is defined because many of protocols handle case sensitive or case insensitive string comparison and therefore preparation of string is mandatory. As described in IDNA mapping [RFC5895] and PRECIS problem statement [I-D.ietf-precis-problem-statement], mappings in internationalized strings are not limited to case, but also width and/or delimiters are taken into consideration. This document considers mappings other than case mapping in PRECIS context. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-yoneya-precis-mappings-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-yoneya-precis-mappings-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 jefsey@jefsey.com Thu Oct 27 23:54: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 7770921F8797; Thu, 27 Oct 2011 23:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.717 X-Spam-Level: X-Spam-Status: No, score=-101.717 tagged_above=-999 required=5 tests=[AWL=0.567, BAYES_00=-2.599, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n96CquuMP-ob; Thu, 27 Oct 2011 23:54:10 -0700 (PDT) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by ietfa.amsl.com (Postfix) with ESMTP id 26C6D21F8770; Thu, 27 Oct 2011 23:54:03 -0700 (PDT) Received: from 243.96-227-89.dsl.completel.net ([89.227.96.243]:54615 helo=jfcmsc.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1RJgKH-0004cG-B1; Thu, 27 Oct 2011 23:54:02 -0700 Message-Id: <7.0.1.0.2.20111027114817.06d3d9e0@jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 28 Oct 2011 09:00:48 +0200 To: Yoshiro YONEYA ,precis@ietf.org From: JFC Morfin In-Reply-To: <20111026145017.35f865e5.yoshiro.yoneya@jprs.co.jp> References: <20111026145017.35f865e5.yoshiro.yoneya@jprs.co.jp> 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: iab@ietf.org, iucg@ietf.org Subject: Re: [precis] Fw: I-D Action: draft-yoneya-precis-mappings-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: Fri, 28 Oct 2011 06:54:11 -0000 At 07:50 26/10/2011, Yoshiro YONEYA wrote: >Dear all, >I submitted a preliminary mapping document as an individual (no hat). >I'd like to discuss this topic at Taipei. Dear Yoshiro, Being only an IETF user I cannot afford attending its meetings. Here are some IDNA2008 remarks on the concerned topic. 1. Lack of a presentation layer The reason as to why IDNs and Internationalized strings support takes so long is that it is supposed to be the job of an OSI presentation layer, which is absent from the Internet. 1) The IDNA concept and IDNA2003 were based upon a presentation layer patch that did not scale the number of scripts, language specifics, and time (Unicode new versions) very well. 2) IDNA2008 has only partly uncovered, introduced, and implemented the very rich non-OSI way that the Internet supports presentation services. 2. The solution is to be RFC 1958 conformant. As a result, there are three, RFC 1958, well defined issues: 2.1. Single network encoding RFC 1958:3.2: "If there are several ways of doing the same thing, choose one. [...] Duplication of the same protocol functionality should be avoided as far as possible". This means how to make the IDNA2003 and IDNA2008 transition and coexist within end to end Internet protocols. The response is RFC 1958:3.5 "Keep it simple. When in doubt during design, choose the simplest solution." This is why IAB's RFC 6055 "explores issues with Internationalized Domain Names (IDNs) that result from the use of various encoding schemes such as UTF-8 and the ASCII-Compatible Encoding produced by the Punycode algorithm. It focuses on the importance of agreeing on a single encoding and how complicated the state of affairs ends up being as a result of using different encodings today." 2.2. Orthotypography RFC 1958:5.4: "Designs should be fully international, with support for localization (adaptation to local character sets). In particular, there should be a uniform approach to character set tagging for information content." This means that the support of linguistic orthotypography, i.e. scripting syntax, is mandatory (French, Latin language, PRECIS mapping, etc.). However, IDNA2008 could not support it on an end to end basis - RFC 1958:4.3: "Public (i.e. widely visible) names should be in case-independent ASCII. Specifically, this refers to DNS names, and to protocol elements that are transmitted in text format." Therefore, it must be addressed differently - RFC 1958:3.6 "Modularity is good. If you can keep things separate, do so." and RFC 1958:2.3: "Everything else should be done at the fringes.": the response is carried out by fringe to fringe modules. This is the enormous power of IDNA2008: to address (linguistic, application, etc.) diversity by (local, contextual) subsidiarity. 2.3. Scalability RFC 1958:3.1: "Heterogeneity is inevitable and must be supported by design"; RFC 1958:2:1: "The community believes that the goal is connectivity, the tool is the Internet Protocol, and the intelligence is end to end rather than hidden in the network."; RFC 1958:3.3: "All designs must scale readily to very many nodes per site and to many millions of sites". This means that the whole "IDNA" architectural concept is to be reviewed in order for it to be simple, orthotypographic, and scalable fully using IDNA2008 to address the heterogeneity of the linguistic diversity. 3. Consequent need Without considering any other context and technical opportunity, this means that the IDNA2008 should modularly support orthotypography on a fringe to fringe basis so as to readily scale to very many nodes, many millions of sites, and many billions of kinds of (orthotypographic) use. The IDNA2003 fringe is stringprep, which did not scale. IDNA2008 puts punycode at the fringe: therefore, punycode has to transparently scale, and punycode can transparently scale. 3.1. Algorithmic solution How to make punycode scale? RFC 1958 says nearly everything: RFC 1958:6.1 "All designs must fit into the IP security architecture". RFC 1958.6.2: "the primary responsibility of the end users to protect themselves." - RFC 1958:6.5. "To ensure interoperation between endpoints [] one algorithm (or suite of algorithms) should be mandated to ensure the ability to negotiate a [] context between implementations. Without this, implementations might otherwise not have an algorithm in common and not be able to communicate []." RFC 1958:3.8: "Avoid options and parameters whenever possible. Any options and parameters should be configured or negotiated dynamically rather than manually" - punycode is to be enhanced into a "punyplus" strictly punycode conformant algorithm, with (an) extension(s) to be defined. - so it may optionally support applications' orthotypographic needs (upper-cases, variants, etc.) in a simple, dynamic manner. - this must be kept transparent to IDNA2003 and non-enhanced punycode versions. 3.2. Architecturally stable framework solution. The rest is to be deduced from the above requirements: the simplest manner to obtain this and to answer the pertinent questions raised by the Applications AD (Lisa Dussault) after the WG and ITEF/LC is to embed that "simple dynamic manner" in order to serve multi-level applications into an IDNA2008 multi-level service. RFC 5895 exemplifies one of them. The term "ML-DNS", standing for multilayer DNS front-end service, generalizes the concept. Once you have accepted this, you see that there still is a lot of architectural work, but that this architectural work: 1. is orthogonal to the "punyplus" design. 2. will only better house and protect the punycode/punyplus function. 4. Implementation 4.1. Conceptual clarification RFC 1958:4.2 "A single naming structure should be used." RFC 1958:3.12: "All specifications should use the same terminology and notation, and the same bit- and byte-order convention". This means that the priority should be to unify DNs and IDNs into a single Internet Domain Name System (IDNS) that could interoperate with other technologies' DNS and be documented simply and by using the same terms and models. 4.2. Intertesting RFC 1958:3.14 "And perhaps most important: Nothing gets standardised until there are multiple instances of running code." The whole issue should be tested. This means that once the current WG/PRECIS, happianna, ICANN variants, IAB and IUCG inputs are gathered (RFC 1958:3.7 "In many cases it is better to adopt an almost complete solution now, rather than to wait until a perfect solution can be found"), it should be the right time to document an experiment on an architectural framework at a fringe IDNs use Interface (IUI) that is able to support the multiple IDN layers (ASCII, UTF-8, with/without uppercase, etc.) that are actually being discussed. However, an "intertest" charter, i.e. the terms and conditions for the community to use the Internet as the test-bed of its own evolution, should be crafted first based on RFCs and ICANN/ICP-3 various lists of constraints. jfc >-- >Yoshiro YONEYA > >Begin forwarded message: > >Date: Mon, 24 Oct 2011 03:09:24 -0700 >From: internet-drafts@ietf.org >To: i-d-announce@ietf.org >Subject: I-D Action: draft-yoneya-precis-mappings-00.txt > > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > Title : Mapping characters for PRECIS classes > Author(s) : Yoshiro YONEYA > Filename : draft-yoneya-precis-mappings-00.txt > Pages : 9 > Date : 2011-10-24 > > Preparation and comparison of internationalized strings > ("PRECIS") > Framework [I-D.ietf-precis-framework] is defining several classes of > strings for preparation and comparison. In the document, case > mapping is defined because many of protocols handle case sensitive or > case insensitive string comparison and therefore preparation of > string is mandatory. As described in IDNA mapping [RFC5895] and > PRECIS problem statement [I-D.ietf-precis-problem-statement], > mappings in internationalized strings are not limited to case, but > also width and/or delimiters are taken into consideration. This > document considers mappings other than case mapping in PRECIS > context. > > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-yoneya-precis-mappings-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-yoneya-precis-mappings-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 > > > >_______________________________________________ >precis mailing list >precis@ietf.org >https://www.ietf.org/mailman/listinfo/precis From stpeter@stpeter.im Fri Oct 28 09:37: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 7899421F87FC for ; Fri, 28 Oct 2011 09:37:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.674 X-Spam-Level: X-Spam-Status: No, score=-102.674 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o8jElwISQrVF for ; Fri, 28 Oct 2011 09:37:15 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id D352221F8663 for ; Fri, 28 Oct 2011 09:37:15 -0700 (PDT) Received: from dhcp-64-101-72-205.cisco.com (unknown [64.101.72.205]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 019F141FC7; Fri, 28 Oct 2011 10:42:36 -0600 (MDT) Message-ID: <4EAADA3A.4080406@stpeter.im> Date: Fri, 28 Oct 2011 10:37:14 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Yoshiro YONEYA References: <20111020183230.ba042696.yoshiro.yoneya@jprs.co.jp> In-Reply-To: <20111020183230.ba042696.yoshiro.yoneya@jprs.co.jp> X-Enigmail-Version: 1.3.2 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: precis@ietf.org Subject: Re: [precis] IETF82 Taipei 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: Fri, 28 Oct 2011 16:37:16 -0000 On 10/20/11 3:32 AM, Yoshiro YONEYA wrote: > Dear all, > > Following is draft agenda for IETF 82 Taipei. Please send > comments/additions/changes to the chairs. > > 1. Administrativia > 2. WG I-Ds > 2.1 Problem-statement > 2.2 Framework > 3. Discussion > 3.1 Internationalized passwords > 3.2 Mappings other than case > 4. Next steps Another discussion item might be the possible need to define subclasses. Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Fri Oct 28 09:41: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 7C27D21F8770 for ; Fri, 28 Oct 2011 09:41:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.672 X-Spam-Level: X-Spam-Status: No, score=-102.672 tagged_above=-999 required=5 tests=[AWL=-0.073, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ws5atpe9TBm9 for ; Fri, 28 Oct 2011 09:41:16 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 4C16121F86C3 for ; Fri, 28 Oct 2011 09:41:13 -0700 (PDT) Received: from dhcp-64-101-72-205.cisco.com (unknown [64.101.72.205]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id C25E141FC7; Fri, 28 Oct 2011 10:46:34 -0600 (MDT) Message-ID: <4EAADB27.1040703@stpeter.im> Date: Fri, 28 Oct 2011 10:41:11 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: precis@ietf.org References: <20111026145017.35f865e5.yoshiro.yoneya@jprs.co.jp> In-Reply-To: <20111026145017.35f865e5.yoshiro.yoneya@jprs.co.jp> X-Enigmail-Version: 1.3.2 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [precis] Fw: I-D Action: draft-yoneya-precis-mappings-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: Fri, 28 Oct 2011 16:41:17 -0000 On 10/25/11 11:50 PM, Yoshiro YONEYA wrote: > Dear all, > > I submitted a preliminary mapping document as an individual (no hat). > I'd like to discuss this topic at Taipei. Thank you, Yoneya-san. I think you've asked some good questions and I look forward to discussing them in Taipei. Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Fri Oct 28 09:46: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 A354821F8A4E for ; Fri, 28 Oct 2011 09:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.67 X-Spam-Level: X-Spam-Status: No, score=-102.67 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQ5sh-ZmUkOi for ; Fri, 28 Oct 2011 09:46:18 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id EDA9E21F86C3 for ; Fri, 28 Oct 2011 09:46:17 -0700 (PDT) Received: from dhcp-64-101-72-205.cisco.com (unknown [64.101.72.205]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 5C43041FC7 for ; Fri, 28 Oct 2011 10:51:39 -0600 (MDT) Message-ID: <4EAADC58.6070405@stpeter.im> Date: Fri, 28 Oct 2011 10:46:16 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "precis@ietf.org" References: <4E9DB87B.6090004@stpeter.im> <9B57C850BB53634CACEC56EF4853FF653B29D991@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B29D991@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> X-Enigmail-Version: 1.3.2 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [precis] do we need both SecretClass and FreeClass? 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, 28 Oct 2011 16:46:18 -0000 Since we seem to have rough consensus on this, last night I worked on removing the SecretClass from the framework spec. I take it as a good sign that this didn't require major surgery. :) I'll submit a revised I-D before the cutoff on Monday. On 10/19/11 4:56 PM, Dave Thaler wrote: > That sounds right to me. > > -Dave > > -----Original Message----- > From: precis-bounces@ietf.org [mailto:precis-bounces@ietf.org] On Behalf Of Peter Saint-Andre > Sent: Tuesday, October 18, 2011 10:34 AM > To: precis@ietf.org > Subject: [precis] do we need both SecretClass and FreeClass? > > As previously mentioned, I posted to the saag@ietf.org list requesting input on internationalized passwords... > > http://www.ietf.org/mail-archive/web/saag/current/msg03476.html > > Yaron Sheffer asked: "how can you disallow space characters (presumably including ASCII SPACE) from the Secret Class?" > > If we say that spaces are valid in the SecretClass, then there is no difference between the SecretClass and the FreeClass. That might be a fine outcome (fewer classes to define and implement), but I wanted to check with the WG before making that change in the framework spec. > > Thanks! > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ > > > _______________________________________________ > precis mailing list > precis@ietf.org > https://www.ietf.org/mailman/listinfo/precis > -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Fri Oct 28 13: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 2501221F8508 for ; Fri, 28 Oct 2011 13:43:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.513 X-Spam-Level: X-Spam-Status: No, score=-102.513 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jsZEqetbl8zd for ; Fri, 28 Oct 2011 13:43:02 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id A67E021F84F8 for ; Fri, 28 Oct 2011 13:43:02 -0700 (PDT) Received: from dhcp-64-101-72-205.cisco.com (unknown [64.101.72.205]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 844AA41FC7; Fri, 28 Oct 2011 14:48:24 -0600 (MDT) Message-ID: <4EAB13D5.7070705@stpeter.im> Date: Fri, 28 Oct 2011 14:43:01 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: =?UTF-8?B?UGF0cmlrIEbDpGx0c3Ryw7Zt?= References: <4E9DBD27.8050600@stpeter.im> <20111018181159.GG13166@shinkuro.com> <4E9DC243.4040803@stpeter.im> <11733D0D-0C58-4415-BE7B-40EC025E0B49@frobbit.se> In-Reply-To: <11733D0D-0C58-4415-BE7B-40EC025E0B49@frobbit.se> X-Enigmail-Version: 1.3.2 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: precis@ietf.org Subject: Re: [precis] passwords as octet strings 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, 28 Oct 2011 20:43:03 -0000 On 10/18/11 1:20 PM, Patrik Fältström wrote: > > On 18 okt 2011, at 20:15, Peter Saint-Andre wrote: > >>>> However, we might want to provide some text in the security >>>> considerations about the desirability (or not) of full-Unicode passwords. >>> >>> I'm slow, but what's the security consideration? There are >>> interoperability considerations: if two applications want to >>> co-operate in authentication, then they're going to need to use >>> Unicode or make up their own protocol. >> >> Right, it's text about interoperability. Where exactly that belongs is >> another matter. I'm happy to add a section about interoperability. > > Please separate the question on what charset (including encoding) is used in the protocol with how comparisons (etc) is done. What is the responsibility on the "client" and "server", etc. Here is proposed text. ### Although strings that are consumed in PRECIS-based application protocols are often encoded using UTF-8 [RFC3629], the exact encoding is a matter for the using protocol, not the PRECIS framework. It is known that some existing systems are unable to support the full Unicode character set, or even any characters outside the US-ASCII range. If two (or more) applications need to interoperate when exchanging data (e.g., for the purpose of authenticating a username or password), they will naturally need have in common at least one coded character set (as defined by [RFC6365]). Establishing such a baseline is a matter for the using protocol, not the PRECIS framework. ### From internet-drafts@ietf.org Sun Oct 30 10:20:28 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 3530621F8B61; Sun, 30 Oct 2011 10:20:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KE1qIazOkOMW; Sun, 30 Oct 2011 10:20:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA09721F8B36; Sun, 30 Oct 2011 10:20:27 -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.62 Message-ID: <20111030172027.32293.57925.idtracker@ietfa.amsl.com> Date: Sun, 30 Oct 2011 10:20:27 -0700 Cc: precis@ietf.org Subject: [precis] I-D Action: draft-ietf-precis-framework-01.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2011 17:20:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Preparation and Comparison of Interna= tionalized Strings Working Group of the IETF. Title : PRECIS Framework: Handling Internationalized Strings in = Protocols Author(s) : Marc Blanchet Peter Saint-Andre Filename : draft-ietf-precis-framework-01.txt Pages : 27 Date : 2011-10-30 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 appl= ication 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 application technologies other than the Domain Name System (DNS). This document obsoletes RFC 3454. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-precis-framework-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-precis-framework-01.txt From duerst@it.aoyama.ac.jp Mon Oct 31 00:16: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 6C27E11E80BA for ; Mon, 31 Oct 2011 00:16:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.493 X-Spam-Level: X-Spam-Status: No, score=-99.493 tagged_above=-999 required=5 tests=[AWL=0.297, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ly9apTtmg1Hk for ; Mon, 31 Oct 2011 00:16:13 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 9DCBF11E80B4 for ; Mon, 31 Oct 2011 00:16:08 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id p9V7Fwwh029980 for ; Mon, 31 Oct 2011 16:15:58 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 64df_1744_2e02dcb8_0390_11e1_92c6_001d096c5782; Mon, 31 Oct 2011 16:15:57 +0900 Received: from [IPv6:::1] ([133.2.210.1]:57359) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 31 Oct 2011 16:15:58 +0900 Message-ID: <4EAE4B27.80902@it.aoyama.ac.jp> Date: Mon, 31 Oct 2011 16:15:51 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Peter Saint-Andre References: <4E9DBD27.8050600@stpeter.im> <20111018181159.GG13166@shinkuro.com> <4E9DC243.4040803@stpeter.im> <11733D0D-0C58-4415-BE7B-40EC025E0B49@frobbit.se> <4EAB13D5.7070705@stpeter.im> In-Reply-To: <4EAB13D5.7070705@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: precis@ietf.org Subject: Re: [precis] passwords as octet strings 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, 31 Oct 2011 07:16:14 -0000 On 2011/10/29 5:43, Peter Saint-Andre wrote: > On 10/18/11 1:20 PM, Patrik Fältström wrote: >> >> On 18 okt 2011, at 20:15, Peter Saint-Andre wrote: >> >>>>> However, we might want to provide some text in the security >>>>> considerations about the desirability (or not) of full-Unicode passwords. For the record, there are other issues which make using full Unicode passwords a problem. They mainly stem from the fact that you can't see a password when you type it. This for example makes it very difficult to e.g. use passwords with Han characters, because they are usually input by using a phonetic method and then verifying/tweaking the converted result. [I don't think there's a need for this fact to go into the document.] Regards, Martin. >>>> I'm slow, but what's the security consideration? There are >>>> interoperability considerations: if two applications want to >>>> co-operate in authentication, then they're going to need to use >>>> Unicode or make up their own protocol. >>> >>> Right, it's text about interoperability. Where exactly that belongs is >>> another matter. I'm happy to add a section about interoperability. >> >> Please separate the question on what charset (including encoding) is used in the protocol with how comparisons (etc) is done. What is the responsibility on the "client" and "server", etc. > > Here is proposed text. > > ### > > Although strings that are consumed in PRECIS-based application > protocols are often encoded using UTF-8 [RFC3629], the exact encoding > is a matter for the using protocol, not the PRECIS framework. > > It is known that some existing systems are unable to support the full > Unicode character set, or even any characters outside the US-ASCII > range. If two (or more) applications need to interoperate when > exchanging data (e.g., for the purpose of authenticating a username > or password), they will naturally need have in common at least one > coded character set (as defined by [RFC6365]). Establishing such a > baseline is a matter for the using protocol, not the PRECIS > framework. > > ### > > _______________________________________________ > precis mailing list > precis@ietf.org > https://www.ietf.org/mailman/listinfo/precis From jefsey@gmail.com Mon Oct 31 03:48:21 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 183AF21F8D02; Mon, 31 Oct 2011 03:48:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.677 X-Spam-Level: X-Spam-Status: No, score=-102.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S9zRCRyFjjkb; Mon, 31 Oct 2011 03:48:20 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0DCA921F8D00; Mon, 31 Oct 2011 03:48:19 -0700 (PDT) Received: by qyk34 with SMTP id 34so3473473qyk.10 for ; Mon, 31 Oct 2011 03:48:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=IonBYjc8ifVIlSvgzZQsRCQAPew5Jqoak/xWsXari2Y=; b=U2tW8LfTQeKP0NLxGy7uWlL3YEAQ3aHTB+iwZqQ4E1BPbywdPbZ4zv63FBPuT9H/+s UFChrloY03aoxS7YGI0LzIKw25O8hEniSoaKT3vrl+kCfH4dIdpIDKY3nyBclyNQBZYO jK2OcgtR9JbNhWIb3+VpyRgOAJNB8hwirDn80= MIME-Version: 1.0 Received: by 10.182.227.7 with SMTP id rw7mr2728938obc.70.1320058099447; Mon, 31 Oct 2011 03:48:19 -0700 (PDT) Sender: jefsey@gmail.com Received: by 10.182.116.9 with HTTP; Mon, 31 Oct 2011 03:48:19 -0700 (PDT) In-Reply-To: <4EAE4B27.80902@it.aoyama.ac.jp> References: <4E9DBD27.8050600@stpeter.im> <20111018181159.GG13166@shinkuro.com> <4E9DC243.4040803@stpeter.im> <11733D0D-0C58-4415-BE7B-40EC025E0B49@frobbit.se> <4EAB13D5.7070705@stpeter.im> <4EAE4B27.80902@it.aoyama.ac.jp> Date: Mon, 31 Oct 2011 11:48:19 +0100 X-Google-Sender-Auth: 2xKgmrr3iiBNA8iadQ8sCmU6geg Message-ID: From: JFC Morfin To: =?ISO-8859-1?B?Ik1hcnRpbiBKLiBE/HJzdCI=?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: precis@ietf.org, iucg@ietf.org Subject: Re: [precis] passwords as octet strings 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, 31 Oct 2011 10:48:21 -0000 This is why I would prefer an open list of criteria rather than a few classes gathering rigidly a few of them. Special needs would be more easily addressed. jfc 2011/10/31, "Martin J. D=FCrst" : > On 2011/10/29 5:43, Peter Saint-Andre wrote: >> On 10/18/11 1:20 PM, Patrik F=E4ltstr=F6m wrote: >>> >>> On 18 okt 2011, at 20:15, Peter Saint-Andre wrote: >>> >>>>>> However, we might want to provide some text in the security >>>>>> considerations about the desirability (or not) of full-Unicode >>>>>> passwords. > > For the record, there are other issues which make using full Unicode > passwords a problem. They mainly stem from the fact that you can't see a > password when you type it. This for example makes it very difficult to > e.g. use passwords with Han characters, because they are usually input > by using a phonetic method and then verifying/tweaking the converted resu= lt. > > [I don't think there's a need for this fact to go into the document.] > > Regards, Martin. > > >>>>> I'm slow, but what's the security consideration? There are >>>>> interoperability considerations: if two applications want to >>>>> co-operate in authentication, then they're going to need to use >>>>> Unicode or make up their own protocol. >>>> >>>> Right, it's text about interoperability. Where exactly that belongs is >>>> another matter. I'm happy to add a section about interoperability. >>> >>> Please separate the question on what charset (including encoding) is us= ed >>> in the protocol with how comparisons (etc) is done. What is the >>> responsibility on the "client" and "server", etc. >> >> Here is proposed text. >> >> ### >> >> Although strings that are consumed in PRECIS-based application >> protocols are often encoded using UTF-8 [RFC3629], the exact encodin= g >> is a matter for the using protocol, not the PRECIS framework. >> >> It is known that some existing systems are unable to support the ful= l >> Unicode character set, or even any characters outside the US-ASCII >> range. If two (or more) applications need to interoperate when >> exchanging data (e.g., for the purpose of authenticating a username >> or password), they will naturally need have in common at least one >> coded character set (as defined by [RFC6365]). Establishing such a >> baseline is a matter for the using protocol, not the PRECIS >> framework. >> >> ### >> >> _______________________________________________ >> precis mailing list >> precis@ietf.org >> https://www.ietf.org/mailman/listinfo/precis > _______________________________________________ > precis mailing list > precis@ietf.org > https://www.ietf.org/mailman/listinfo/precis >