From stpeter@stpeter.im Tue May 17 09:29:26 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 EEC9EE0748 for ; Tue, 17 May 2011 09:29:26 -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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IjeKvlD9YMA0 for ; Tue, 17 May 2011 09:29:26 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 08B8BE0746 for ; Tue, 17 May 2011 09:29:26 -0700 (PDT) Received: from dhcp-64-101-72-204.cisco.com (dhcp-64-101-72-204.cisco.com [64.101.72.204]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 5280740046 for ; Tue, 17 May 2011 10:29:25 -0600 (MDT) Message-ID: <4DD2A264.3040001@stpeter.im> Date: Tue, 17 May 2011 10:29:24 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: precis@ietf.org X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000100080300090502040600" Subject: [precis] Fwd: I-D Action: draft-blanchet-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: Tue, 17 May 2011 16:29:27 -0000 This is a cryptographically signed message in MIME format. --------------ms000100080300090502040600 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This document attempts to incorporate the rough proposal I outlined in Prague. It still contains a number of open issues. Feedback is very much welcome! /psa -------- Original Message -------- Subject: I-D Action: draft-blanchet-precis-framework-01.txt Date: Tue, 17 May 2011 09:22:44 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : PRECIS Framework: Handling Internationalized Strings in Protocols Author(s) : Marc Blanchet Peter Saint-Andre Filename : draft-blanchet-precis-framework-01.txt Pages : 24 Date : 2011-05-17 Application protocols that make use of Unicode code points in protocol strings need to prepare such strings in order to perform comparison operations (e.g., for purposes of authentication or authorization). In general, this problem has been labeled the "preparation and comparison of internationalized strings" or= "PRECIS". This document defines a framework that enables application protocols to prepare various classes of strings in a way that depends on the properties of Unicode code points. Because this framework does not depend on large tables of Unicode code points as in stringprep (RFC 3454), it is more agile with regard to changes in the underlying Unicode database and thus provides improved flexibility to application protocols. A specification that reuses 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 non-IDNA technologies. This document obsoletes RFC 3454. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-blanchet-precis-framework-01.tx= t Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-blanchet-precis-framework-01.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 --------------ms000100080300090502040600 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDUx NzE2MjkyNFowIwYJKoZIhvcNAQkEMRYEFJEfOsnaXcr2X9+hFt55VEhbVhTJMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQAPSTQ6K/I3gBHF0agA5PgpT7ZdVPqMhZsmnQ5aW4N00vJMQzuk0XMeYShr XyWwCKfgX1DWgBfQ59zo5TfCEs4vyPVpHDz82QG8bxIh9frwtTegtKD+mxltLu6R/JkHk7Jk OjW7p/v5QumMwJXzyCbtB2bSVuP92IOMSbqvrqMTTpEDiCV5sRbIRUNzf4xwyRxeTdHrJz0+ 9KwITgljAJa9L/Qfm3x+bPb4LRSxRbOxYYTWoux7nXduxafvUn1x2vFqVUPXXT0QqMlfhTFL Mhhve3igVoAInlxw+oUDvOdNsc2JjT0G5TTGvBk+UV7Ju2449/3ECUxHnI/FKR4549bxAAAA AAAA --------------ms000100080300090502040600-- From marc.blanchet@viagenie.ca Wed May 18 00:49:46 2011 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31801E069E for ; Wed, 18 May 2011 00:49:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WEPj45g-tCCM for ; Wed, 18 May 2011 00:49:45 -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 405B3E0694 for ; Wed, 18 May 2011 00:49:45 -0700 (PDT) Received: from mbl.local (jazz.viagenie.ca [206.123.31.2]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 4A59321E3E for ; Wed, 18 May 2011 03:49:43 -0400 (EDT) Message-ID: <4DD37A15.9050401@viagenie.ca> Date: Wed, 18 May 2011 09:49:41 +0200 From: Marc Blanchet User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; fr; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: precis@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [precis] minutes of Prague precis wg meeting 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, 18 May 2011 07:49:46 -0000 Hello, please find minutes of Prague precis wg meeting, written by Yoneya-san. Please send edits to the co-chairs. Regards, Marc. http://www.ietf.org/proceedings/80/minutes/precis.txt ====================================================================== IETF80 Precis wg meeting minutes Prague, Czech 2011-03-31 Problem Statement -02 has published, few cleanups. Feedback to Framework from XMPP Classifying strings into 4 types was proposed: - domainythings - nameythings - wordythings - stringythings Name of wordything was pointed out as confusing, another name such as secretthing was preferred. Consensus of the room was to go with the proposed direction. Next step Will have interim meeting before Quebec IETF, may be in middle-end of May. ====================================================================== From florob@babelmonkeys.de Fri May 20 18:02:51 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 84C5AE068B for ; Fri, 20 May 2011 18:02:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tDc49oJs72l3 for ; Fri, 20 May 2011 18:02:50 -0700 (PDT) Received: from babelmonkeys.de (unknown [IPv6:2a01:4f8:140:9341:a2b3::ab]) by ietfa.amsl.com (Postfix) with ESMTP id C6FEBE0665 for ; Fri, 20 May 2011 18:02:48 -0700 (PDT) Received: from xdsl-213-196-246-162.netcologne.de ([213.196.246.162] helo=[192.168.0.38]) by babelmonkeys.de with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1QNaad-0001O2-3Q for precis@ietf.org; Sat, 21 May 2011 03:02:47 +0200 Message-ID: <4DD70F31.4080308@babelmonkeys.de> Date: Sat, 21 May 2011 03:02:41 +0200 From: Florian Zeitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: precis@ietf.org References: <4DD2A264.3040001@stpeter.im> In-Reply-To: <4DD2A264.3040001@stpeter.im> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [precis] Fwd: I-D Action: draft-blanchet-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: Sat, 21 May 2011 01:02:51 -0000 Am 17.05.2011 18:29, schrieb Peter Saint-Andre: > This document attempts to incorporate the rough proposal I outlined in > Prague. It still contains a number of open issues. Feedback is very much > welcome! > > /psa > Hy, this is some feedback based on an initial read-through. It contains both comments and questions that came to mind during reading. The questions are largely unfiltered (i.e. answers to them became somewhat apparent after having read the whole document) in the hope that this will help identify areas where the text could be improved. First of all I maintain that "compatibility equivalent" (used in multiple places) is the wrong term. Unicode 6.0 Chapter 3.7 defines compatibility equivalent by their full compatibility decompositions being identical. Compatibility decomposition in turn however is defined as the result of applying both compatibility mappings and canonical mappings. That is different from the definition NFKC(cp) == cp. I think the proper wording for the category Q is "All compatibility decomposable characters". As someone else had mentioned in Prague I too am not sure "Wordything" is a good expression for passwords. While passwords are words in the sense of being elements of L((((A|Q)\(L|N|O|P))|K)*) (i.e. The language described by the regular expression that (hopefully) describes Wordything) people tend to think of words as "Those things listed in a dictionary" which is precisely what we don't want people to use as password. I understand Stringything stems from XMPP's resources. However the draft describes it as being used for nick-names. It is not clear to me what the argument for differentiating nick-names and normal names is. Especially considering both potentially need to be entered by a end-user. Having a Valid and a Disallowed rule was quite confusing. Especially considering that Valid rules contain exceptions from the Disallowed rule and vice-versa. Some of the questions that sprung to mind were: What about code points that are neither matched by the Valid nor the Disallowed rule? Can that happen? Is the union of both sets (Valid and Disallowed) the set of all Unicode code points? Is it guaranteed to stay that way in future Unicode versions? Also theses rules don't describe behaviour for CONTEXT? code points. The draft says in a lot of places that directionality, case-mapping and normalization rules are application specific (At least sections 3, 3.{1,2,3}.{4,5,6} and 4.1). That seams rather redundant. Maybe that's just me, but if we specify that applications need to specify how to do normalization I think it might be worthwhile to give some guidance on when to normalize strings. The OPEN ISSUE in section 3.2.5 suggests mapping uppercase and titlecase code points to their lowercase equivalents maximizes entropy. Maybe I'm just confused, but doesn't that effectively reduce the set of possible characters and therefore entropy? Personally I think saying it's NOT RECOMMENDED for application protocols to perform such mappings is the right thing to do. Furthermore I think allowing symbols and punctuation is the right thing to do. In the age of laptops not being able to type your password any more should be less of a problem. The Unassigned rule states that not yet assigned code points are to be considered Unassigned. To me that seems not only trivial, but especially doesn't appear to be a rule on how to handle unassigned code points at all... The fact that code points can only have one derived property appears strange to me. It makes the algorithm non-deterministic in that it sometimes sets the derived property to one of three values. I think allowing multiple derived properties at the same time might be clearer. Is it expected that people will calculate derived properties themselves, or look them up in a to be created normative table separate from the RFC? It seams to me that the former would need a complete Unicode table and an implementation of a relatively complex algorithm, while the later is a simple table lookup from a smaller table. However the former still seems more elegant... And last and least a remark: IIRC what was agreed on was a inclusive approach only disallowing certain characters. The pseudo-code however defaults to DISALLOWED if no class was matched. That seems right to me, but implies we are still using an approach that is only allowing certain characters, however it's more flexible and version agile. -- Florian Zeitz > -------- Original Message -------- > Subject: I-D Action: draft-blanchet-precis-framework-01.txt > Date: Tue, 17 May 2011 09:22:44 -0700 > From: internet-drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : PRECIS Framework: Handling Internationalized Strings > in Protocols > Author(s) : Marc Blanchet > Peter Saint-Andre > Filename : draft-blanchet-precis-framework-01.txt > Pages : 24 > Date : 2011-05-17 > > Application protocols that make use of Unicode code points in > protocol strings need to prepare such strings in order to perform > comparison operations (e.g., for purposes of authentication or > authorization). In general, this problem has been labeled the > "preparation and comparison of internationalized strings" or > "PRECIS". This document defines a framework that enables > application > protocols to prepare various classes of strings in a way that depends > on the properties of Unicode code points. Because this framework > does not depend on large tables of Unicode code points as in > stringprep (RFC 3454), it is more agile with regard to changes in the > underlying Unicode database and thus provides improved flexibility to > application protocols. A specification that reuses 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 non-IDNA > technologies. This document obsoletes RFC 3454. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-blanchet-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-blanchet-precis-framework-01.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 marc.blanchet@viagenie.ca Sat May 21 02:55:09 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 A9986E067C for ; Sat, 21 May 2011 02:55:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.89 X-Spam-Level: X-Spam-Status: No, score=-101.89 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UQFLRK6b08vk for ; Sat, 21 May 2011 02:55:08 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id 5B2E2E0658 for ; Sat, 21 May 2011 02:55:07 -0700 (PDT) Received: from mbl.local (unknown [91.137.20.132]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 29F9320D1D for ; Sat, 21 May 2011 05:55:04 -0400 (EDT) Message-ID: <4DD78BF5.5020104@viagenie.ca> Date: Sat, 21 May 2011 11:55:01 +0200 From: Marc Blanchet User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; fr; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: precis@ietf.org References: <4DD2A264.3040001@stpeter.im> <4DD70F31.4080308@babelmonkeys.de> In-Reply-To: <4DD70F31.4080308@babelmonkeys.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [precis] Fwd: I-D Action: draft-blanchet-precis-framework-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: Sat, 21 May 2011 09:55:09 -0000 Florian, - thanks for your input. - regarding your points on the properties, building tables, ...: we took roughly the same approach as IDNAbis (RFC5892) on purpose. About building the tables, as with IDNAbis, a registry would be setup similarly to http://www.iana.org/assignments/idnabis-tables Regards, Marc. Le 11-05-21 03:02, Florian Zeitz a écrit : > Am 17.05.2011 18:29, schrieb Peter Saint-Andre: >> This document attempts to incorporate the rough proposal I outlined in >> Prague. It still contains a number of open issues. Feedback is very much >> welcome! >> >> /psa >> > Hy, > > this is some feedback based on an initial read-through. It contains both > comments and questions that came to mind during reading. > The questions are largely unfiltered (i.e. answers to them became > somewhat apparent after having read the whole document) in the hope that > this will help identify areas where the text could be improved. > > First of all I maintain that "compatibility equivalent" (used in > multiple places) is the wrong term. Unicode 6.0 Chapter 3.7 defines > compatibility equivalent by their full compatibility decompositions > being identical. Compatibility decomposition in turn however is defined > as the result of applying both compatibility mappings and canonical > mappings. > That is different from the definition NFKC(cp) == cp. > I think the proper wording for the category Q is "All compatibility > decomposable characters". > > As someone else had mentioned in Prague I too am not sure "Wordything" > is a good expression for passwords. While passwords are words in the > sense of being elements of L((((A|Q)\(L|N|O|P))|K)*) (i.e. The language > described by the regular expression that (hopefully) describes > Wordything) people tend to think of words as "Those things listed in a > dictionary" which is precisely what we don't want people to use as password. > > I understand Stringything stems from XMPP's resources. > However the draft describes it as being used for nick-names. It is not > clear to me what the argument for differentiating nick-names and normal > names is. Especially considering both potentially need to be entered by > a end-user. > > Having a Valid and a Disallowed rule was quite confusing. Especially > considering that Valid rules contain exceptions from the Disallowed rule > and vice-versa. > Some of the questions that sprung to mind were: > What about code points that are neither matched by the Valid nor the > Disallowed rule? Can that happen? > Is the union of both sets (Valid and Disallowed) the set of all Unicode > code points? Is it guaranteed to stay that way in future Unicode versions? > Also theses rules don't describe behaviour for CONTEXT? code points. > > The draft says in a lot of places that directionality, case-mapping and > normalization rules are application specific (At least sections 3, > 3.{1,2,3}.{4,5,6} and 4.1). That seams rather redundant. > > Maybe that's just me, but if we specify that applications need to > specify how to do normalization I think it might be worthwhile to give > some guidance on when to normalize strings. > > The OPEN ISSUE in section 3.2.5 suggests mapping uppercase and titlecase > code points to their lowercase equivalents maximizes entropy. Maybe I'm > just confused, but doesn't that effectively reduce the set of possible > characters and therefore entropy? > Personally I think saying it's NOT RECOMMENDED for application protocols > to perform such mappings is the right thing to do. > Furthermore I think allowing symbols and punctuation is the right thing > to do. In the age of laptops not being able to type your password any > more should be less of a problem. > > The Unassigned rule states that not yet assigned code points are to be > considered Unassigned. To me that seems not only trivial, but especially > doesn't appear to be a rule on how to handle unassigned code points at > all... > > The fact that code points can only have one derived property appears > strange to me. It makes the algorithm non-deterministic in that it > sometimes sets the derived property to one of three values. I think > allowing multiple derived properties at the same time might be clearer. > > Is it expected that people will calculate derived properties themselves, > or look them up in a to be created normative table separate from the > RFC? It seams to me that the former would need a complete Unicode table > and an implementation of a relatively complex algorithm, while the > later is a simple table lookup from a smaller table. > However the former still seems more elegant... > > And last and least a remark: IIRC what was agreed on was a inclusive > approach only disallowing certain characters. The pseudo-code however > defaults to DISALLOWED if no class was matched. > That seems right to me, but implies we are still using an approach that > is only allowing certain characters, however it's more flexible and > version agile. > > -- > Florian Zeitz > >> -------- Original Message -------- >> Subject: I-D Action: draft-blanchet-precis-framework-01.txt >> Date: Tue, 17 May 2011 09:22:44 -0700 >> From: internet-drafts@ietf.org >> Reply-To: internet-drafts@ietf.org >> To: i-d-announce@ietf.org >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> Title : PRECIS Framework: Handling Internationalized Strings >> in Protocols >> Author(s) : Marc Blanchet >> Peter Saint-Andre >> Filename : draft-blanchet-precis-framework-01.txt >> Pages : 24 >> Date : 2011-05-17 >> >> Application protocols that make use of Unicode code points in >> protocol strings need to prepare such strings in order to perform >> comparison operations (e.g., for purposes of authentication or >> authorization). In general, this problem has been labeled the >> "preparation and comparison of internationalized strings" or >> "PRECIS". This document defines a framework that enables >> application >> protocols to prepare various classes of strings in a way that depends >> on the properties of Unicode code points. Because this framework >> does not depend on large tables of Unicode code points as in >> stringprep (RFC 3454), it is more agile with regard to changes in the >> underlying Unicode database and thus provides improved flexibility to >> application protocols. A specification that reuses 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 non-IDNA >> technologies. This document obsoletes RFC 3454. >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-blanchet-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-blanchet-precis-framework-01.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 > > _______________________________________________ > precis mailing list > precis@ietf.org > https://www.ietf.org/mailman/listinfo/precis -- ========= IETF81 Quebec city: http://ietf81.ca IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca DTN Implementation: http://postellation.viagenie.ca NAT64-DNS64 Opensource: http://ecdysis.viagenie.ca Space Assigned Number Authority: http://sanaregistry.org From david.black@emc.com Mon May 23 13:40: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 8AB1EE0850 for ; Mon, 23 May 2011 13:40:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AqDwAZt7KqoM for ; Mon, 23 May 2011 13:40:29 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id B684DE0830 for ; Mon, 23 May 2011 13:40:29 -0700 (PDT) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p4NKeSvJ008013 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 May 2011 16:40:28 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.145]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Mon, 23 May 2011 16:40:15 -0400 Received: from mxhub20.corp.emc.com (mxhub20.corp.emc.com [10.254.93.49]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p4NKdjcl007343; Mon, 23 May 2011 16:39:45 -0400 Received: from mx14a.corp.emc.com ([169.254.1.245]) by mxhub20.corp.emc.com ([10.254.93.49]) with mapi; Mon, 23 May 2011 16:39:44 -0400 From: To: , Date: Mon, 23 May 2011 16:39:44 -0400 Thread-Topic: iSCSI stringprep profile review added Thread-Index: AcubD9GMv7Aaihm0RhOdK6HcUlCLEB+eVNrQ Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E0588F42980@MX14A.corp.emc.com> References: <4D06951B.6020202@stpeter.im> In-Reply-To: <4D06951B.6020202@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: [precis] iSCSI stringprep profile review added 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, 23 May 2011 20:40:30 -0000 PiBJdCdzIGEgd2lraSwgc28gZmVlbCBmcmVlIHRvIGVkaXQgYXQgd2lsbC4gOikNCg0KaVNDU0kg cmV2aWV3IGp1c3QgdXBsb2FkZWQ6DQoNCmh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL3dnL3By ZWNpcy90cmFjL3RpY2tldC8zDQoNCg0KVGhhbmtzLA0KLS1EYXZpZA0KLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KRGF2aWQgTC4gQmxhY2ssIERp c3Rpbmd1aXNoZWQgRW5naW5lZXINCkVNQyBDb3Jwb3JhdGlvbiwgMTc2IFNvdXRoIFN0LiwgSG9w a2ludG9uLCBNQcKgIDAxNzQ4DQorMSAoNTA4KSAyOTMtNzk1M8KgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoCBGQVg6ICsxICg1MDgpIDI5My03Nzg2DQpkYXZpZC5ibGFja0BlbWMuY29twqDCoMKgwqDC oMKgwqAgTW9iaWxlOiArMSAoOTc4KSAzOTQtNzc1NA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+IEZyb206IHByZWNpcy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86cHJlY2lzLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBQZXRlciBTYWludC1BbmRyZQ0KPiBTZW50OiBNb25k YXksIERlY2VtYmVyIDEzLCAyMDEwIDQ6NTAgUE0NCj4gVG86IHByZWNpc0BpZXRmLm9yZw0KPiBT dWJqZWN0OiBbcHJlY2lzXSB1cGRhdGVkIHRlbXBsYXRlDQo+IA0KPiBXaGlsZSB3cml0aW5nIGV2 YWx1YXRpb25zIGZvciBOb2RlcHJlcCBhbmQgUmVzb3VyY2VwcmVwLCBJIHRob3VnaHQgb2YgYQ0K PiBmZXcgbW9yZSBjb25zaWRlcmF0aW9ucyB0aGF0IEkgdGhvdWdodCB3b3VsZCBiZSB1c2VmdWws IHNvIEkndmUgYWRkZWQNCj4gdGhvc2UgdG8gdGhlIHRlbXBsYXRlOg0KPiANCj4gaHR0cDovL3Ry YWMudG9vbHMuaWV0Zi5vcmcvd2cvcHJlY2lzL3RyYWMvd2lraS9TdHJpbmdwcmVwUmV2aWV3VGVt cGxhdGUNCj4gDQo+IEl0J3MgYSB3aWtpLCBzbyBmZWVsIGZyZWUgdG8gZWRpdCBhdCB3aWxsLiA6 KQ0KPiANCj4gUGV0ZXINCj4gDQo+IC0tDQo+IFBldGVyIFNhaW50LUFuZHJlDQo+IGh0dHBzOi8v c3RwZXRlci5pbS8NCj4gDQo+IA0KDQo= From yoshiro.yoneya@jprs.co.jp Mon May 23 18:09:55 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 5D030E07A4 for ; Mon, 23 May 2011 18:09:55 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mye14q3XsJs8 for ; Mon, 23 May 2011 18:09:53 -0700 (PDT) Received: from send12.jprs.co.jp (send12.jprs.co.jp [IPv6:2001:df0:8:6::72]) by ietfa.amsl.com (Postfix) with ESMTP id 78535E07C5 for ; Mon, 23 May 2011 18:09:52 -0700 (PDT) Received: from sendsms12.jprs.co.jp (sendsms12.jprs.co.jp [202.11.17.114]) by send12.jprs.co.jp (8.13.8+Sun/8.13.8) with ESMTP id p4O19hmg013290; Tue, 24 May 2011 10:09:44 +0900 (JST) Received: from sendsms12.jprs.co.jp (unknown [127.0.0.1]) by sendsms12.jprs.co.jp (Symantec Mail Security) with ESMTP id 510153495; Tue, 24 May 2011 10:09:43 +0900 (JST) X-AuditID: ca0b1172-0000000b000010a3-4e-4ddb05564f20 Received: from NOTE550 (off-cpu04.tyo.jprs.co.jp [172.18.4.14]) by sendsms12.jprs.co.jp (Symantec Mail Security) with SMTP id C399D3351; Tue, 24 May 2011 10:09:42 +0900 (JST) Date: Tue, 24 May 2011 10:09:39 +0900 From: Yoshiro YONEYA To: Message-Id: <20110524100939.0807bfb5.yoshiro.yoneya@jprs.co.jp> In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E0588F42980@MX14A.corp.emc.com> References: <4D06951B.6020202@stpeter.im> <7C4DFCE962635144B8FAE8CA11D0BF1E0588F42980@MX14A.corp.emc.com> X-Mailer: Sylpheed 3.1.1 (GTK+ 2.10.14; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: precis@ietf.org Subject: Re: [precis] iSCSI stringprep profile review added 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, 24 May 2011 01:09:55 -0000 Hi, David, Thank you very much for your effort! -- Yoshiro YONEYA On Mon, 23 May 2011 16:39:44 -0400 wrote: > > It's a wiki, so feel free to edit at will. :) > > iSCSI review just uploaded: > > http://trac.tools.ietf.org/wg/precis/trac/ticket/3 > > > Thanks, > --David > ---------------------------------------------------- > David L. Black, Distinguished Engineer > EMC Corporation, 176 South St., Hopkinton, MA  01748 > +1 (508) 293-7953             FAX: +1 (508) 293-7786 > david.black@emc.com        Mobile: +1 (978) 394-7754 > ---------------------------------------------------- > > > -----Original Message----- > > From: precis-bounces@ietf.org [mailto:precis-bounces@ietf.org] On Behalf Of Peter Saint-Andre > > Sent: Monday, December 13, 2010 4:50 PM > > To: precis@ietf.org > > Subject: [precis] updated template > > > > While writing evaluations for Nodeprep and Resourceprep, I thought of a > > few more considerations that I thought would be useful, so I've added > > those to the template: > > > > http://trac.tools.ietf.org/wg/precis/trac/wiki/StringprepReviewTemplate > > > > It's a wiki, so feel free to edit at will. :) > > > > Peter > > > > -- > > Peter Saint-Andre > > https://stpeter.im/ > > > > > > _______________________________________________precis mailing listprecis@ietf.orghttps://www.ietf.org/mailman/listinfo/precis > > From trac+precis@trac.tools.ietf.org Mon May 23 13:38: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 366E0E0853 for ; Mon, 23 May 2011 13:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ct+yQ0IZNnL6 for ; Mon, 23 May 2011 13:38:29 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id D1468E069C for ; Mon, 23 May 2011 13:38:29 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QObtR-0006p9-62; Mon, 23 May 2011 13:38:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "precis issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: david.black@emc.com, marc.blanchet@viagenie.ca X-Trac-Project: precis Date: Mon, 23 May 2011 20:38:25 -0000 X-URL: http://tools.ietf.org/precis/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/precis/trac/ticket/3#comment:3 Message-ID: <075.09004e90584db5c08a111ac7f16c3701@trac.tools.ietf.org> References: <066.f74beb9d344966a703d40044170147f2@trac.tools.ietf.org> X-Trac-Ticket-ID: 3 In-Reply-To: <066.f74beb9d344966a703d40044170147f2@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: david.black@emc.com, marc.blanchet@viagenie.ca, precis@ietf.org X-SA-Exim-Mail-From: trac+precis@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Tue, 24 May 2011 08:01:26 -0700 Cc: precis@ietf.org Subject: Re: [precis] #3: Review RFC3720 and RFC3722 (iSCSI) X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 20:38:30 -0000 #3: Review RFC3720 and RFC3722 (iSCSI) Changes (by david.black@…): * owner: => david.black@… * status: new => assigned * component: => problem-statement -- ---------------------------------------+------------------------------------ Reporter: marc.blanchet@… | Owner: david.black@… Type: task | Status: assigned Priority: major | Milestone: Component: problem-statement | Version: Severity: - | Keywords: ---------------------------------------+------------------------------------ Ticket URL: precis