From kitten-bounces@lists.ietf.org Wed Apr 19 17:46:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWKVA-0007sl-5j; Wed, 19 Apr 2006 17:46:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWKV8-0007sf-Mb for kitten@lists.ietf.org; Wed, 19 Apr 2006 17:46:18 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWKV7-0001fB-F7 for kitten@lists.ietf.org; Wed, 19 Apr 2006 17:46:18 -0400 Received: from [70.192.217.82] (82.sub-70-192-217.myvzw.com [70.192.217.82]) (user=jaltman mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.6/8.13.6) with ESMTP id k3JLkEoK001329 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 19 Apr 2006 17:46:16 -0400 (EDT) Message-ID: <4446B039.9000806@columbia.edu> Date: Wed, 19 Apr 2006 17:48:41 -0400 From: Jeffrey Altman Organization: No Longer Affiliated with Columbia University in the City of New York User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: kitten@lists.ietf.org X-Enigmail-Version: 0.94.0.0 X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Subject: Working Group Last Call (Take Two): Desired Enhancements to GSSAPI Naming X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1377384378==" Errors-To: kitten-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============1377384378== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000705070308000302010409" This is a cryptographically signed message in MIME format. --------------ms000705070308000302010409 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit This note announces the start of a two week working group last call for the Kitten work item "Desired Enhancements to GSSAPI Naming". http://www.ietf.org/internet-drafts/draft-ietf-kitten-gss-naming-04..txt This document is intended to be published as Informational. The document provides scope for the naming issues Kitten is attempting to solve. The author believes that all responses received during the previous WGLC have been addressed. Please perform another review and send feedback to the list stating that the review has been performed regardless of whether or not there are comments. This WGLC ends at 00:00 EST on Thursday May 4, 2006. Jeffrey Altman --------------ms000705070308000302010409 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJPzCC AvowggJjoAMCAQICAw7NrDANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUwNTI3MTc0MjQzWhcNMDYwNTI3MTc0MjQz WjBrMQ8wDQYDVQQEEwZBbHRtYW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMT SmVmZnJleSBFcmljIEFsdG1hbjEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBjb2x1bWJpYS5l ZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+LutDu/YyHreNfoYd+ZtOjXsL h67F2cmcVuBPBz+ZGDA+WpVEHrqXaZZO8acXBR5uAVfiwA1acE/kvD/CN5kAqx1VJuQ8Pvyk iGHhUYTd27ZTliBIrptC7C/381gVwkS+a8jQFPJPO+OktZDzAYplGRY/MQCV8dIsvXUjucox 7TwTTdoLAJYRvHtfEcaCc6mO4ph6NeXQw8Grlx3IRAlTrkE5fBGyjH6R4fqnFTXRQAh1/bG+ i8hQvE6mud3mXdL2t7NP1Qxd9wW0/F/pnWY12IFP/luc3zEzIPvAe+nJluLuSEj0LZgP16mF xBj1p+u9HPWcHRVX6q7+MQ0RWOv1AgMBAAGjMTAvMB8GA1UdEQQYMBaBFGphbHRtYW5AY29s dW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAUDUuzxiq8bbI8vq2 swRK513RphZp+fepyKU5mwBI6aF4GcmqITQILtfTG2SXnjSeY99d+bjOdK1DJFvVh9aOy8mh 2NbEnqMnJIZtg5+eEU64DIV5bQdDRpi99H9vA0sRATIquut+3YHba+zArj0VkVof2VI+ToBu sHdtSrZYo0gwggL6MIICY6ADAgECAgMOzawwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA1MDUyNzE3NDI0M1oXDTA2 MDUyNzE3NDI0M1owazEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMx HDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xIzAhBgkqhkiG9w0BCQEWFGphbHRtYW5A Y29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvi7rQ7v2Mh63 jX6GHfmbTo17C4euxdnJnFbgTwc/mRgwPlqVRB66l2mWTvGnFwUebgFX4sANWnBP5Lw/wjeZ AKsdVSbkPD78pIhh4VGE3du2U5YgSK6bQuwv9/NYFcJEvmvI0BTyTzvjpLWQ8wGKZRkWPzEA lfHSLL11I7nKMe08E03aCwCWEbx7XxHGgnOpjuKYejXl0MPBq5cdyEQJU65BOXwRsox+keH6 pxU10UAIdf2xvovIULxOprnd5l3S9rezT9UMXfcFtPxf6Z1mNdiBT/5bnN8xMyD7wHvpyZbi 7khI9C2YD9ephcQY9afrvRz1nB0VV+qu/jENEVjr9QIDAQABozEwLzAfBgNVHREEGDAWgRRq YWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAFA1 Ls8YqvG2yPL6trMESudd0aYWafn3qcilOZsASOmheBnJqiE0CC7X0xtkl540nmPfXfm4znSt QyRb1YfWjsvJodjWxJ6jJySGbYOfnhFOuAyFeW0HQ0aYvfR/bwNLEQEyKrrrft2B22vswK49 FZFaH9lSPk6AbrB3bUq2WKNIMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAzswggM3AgEB MGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMOzaww CQYFKw4DAhoFAKCCAacwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMDYwNDE5MjE0ODQxWjAjBgkqhkiG9w0BCQQxFgQUnlMu6r+cO48UcI309/2zxGv+ybMw UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw7NrDB6BgsqhkiG9w0B CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AgMOzawwDQYJKoZIhvcNAQEBBQAEggEANj7WzNSBVHIjg6rRs3YvXYLDWMv9h6Nf31RrR9a3 lnFRP+jmNpVrJYi6Hc9OQKCeoxcq+2MW6IYSefYpaX8o9Uw2TVIDM3YlMLggjacQef6aRAQT al5RNluMFz501aBVvn2dryYoHBYI8ILFKajxHk39itldYhhBUglYDyLt6BDnNeKscHcz/nHR VAhtTjkqCZAy1jArO/lXrzAIXXOVESUgB9iMKJe/rYkebKFUMtUo3ASlCRaBxGCmH+iSrJM6 LMj4qObLsv1F3N3Ph+gGqivbw4yax0M7A8DxixM2MXzxpGVoNWAo8OAa/1mzNPfP4D/wyM9N SlKJ828nLF4xrAAAAAAAAA== --------------ms000705070308000302010409-- --===============1377384378== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten --===============1377384378==-- From kitten-bounces@lists.ietf.org Wed Apr 19 17:50:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWKZX-0000ru-2W; Wed, 19 Apr 2006 17:50:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWKZV-0000rk-GC for kitten@lists.ietf.org; Wed, 19 Apr 2006 17:50:49 -0400 Received: from mx2.rbc.com ([142.245.29.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWKZU-0001oT-7n for kitten@lists.ietf.org; Wed, 19 Apr 2006 17:50:49 -0400 Received: from unknown (HELO sew01017.maple.fg.rbc.com) ([10.101.138.27]) by mx2.rbc.com with ESMTP; 19 Apr 2006 17:50:49 -0400 X-IronPort-AV: i="4.04,137,1144036800"; d="scan'208"; a="134514001:sNHT37732840" Received: from sew01074.maple.fg.rbc.com ([10.237.152.92]) by sew01017.maple.fg.rbc.com with Microsoft SMTPSVC(5.0.2195.6920); Wed, 19 Apr 2006 17:50:47 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 19 Apr 2006 17:50:47 -0400 Message-ID: <72BEC87377F1164FB3EF6A88B636507201946365@SEW01074.maple.fg.rbc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Working Group Last Call (Take Two): Desired Enhancements to GSSAPI Naming Thread-Index: AcZj+s+UPjNC8LpOTyC1iufrqibHQwAAGSIA From: "Justad, Paul \(RBC Centura Bank\)" To: "Jeffrey Altman" , X-OriginalArrivalTime: 19 Apr 2006 21:50:47.0735 (UTC) FILETIME=[513A3C70:01C663FB] Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Subject: RE: Working Group Last Call (Take Two): Desired Enhancements to GSSAPI Naming X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org There was an error in the URL, I have corrected it for the group. http://www.ietf.org/internet-drafts/draft-ietf-kitten-gss-naming-04.txt :-) Happy that I could contribute... -----Original Message----- From: Jeffrey Altman [mailto:jaltman@columbia.edu] Sent: Wednesday, April 19, 2006 5:49 PM To: kitten@lists.ietf.org Subject: Working Group Last Call (Take Two): Desired Enhancements to GSSAPI Naming This note announces the start of a two week working group last call for the Kitten work item "Desired Enhancements to GSSAPI Naming". http://www.ietf.org/internet-drafts/draft-ietf-kitten-gss-naming-04..txt This document is intended to be published as Informational. The document provides scope for the naming issues Kitten is attempting to solve. The author believes that all responses received during the previous WGLC have been addressed. Please perform another review and send feedback to the list stating that the review has been performed regardless of whether or not there are comments. This WGLC ends at 00:00 EST on Thursday May 4, 2006. Jeffrey Altman _______________________________________________________________________ This e-mail may be privileged and/or confidential, and the sender does not = waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it conta= ins by other than an intended recipient is unauthorized. If you received this e-mail in error, please advise me (by return e-mail or= otherwise) immediately. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Fri Apr 21 17:24:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FX36r-0003Pf-Ti; Fri, 21 Apr 2006 17:24:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FX36q-0003PK-D8 for kitten@lists.ietf.org; Fri, 21 Apr 2006 17:24:12 -0400 Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FX36q-00083w-0D for kitten@lists.ietf.org; Fri, 21 Apr 2006 17:24:12 -0400 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id XAA12756; Fri, 21 Apr 2006 23:23:48 +0200 (MESZ) From: Martin Rex Message-Id: <200604212123.XAA29342@uw1048.wdf.sap.corp> To: jaltman@columbia.edu (Jeffrey Altman) Date: Fri, 21 Apr 2006 23:23:46 +0200 (MET DST) In-Reply-To: <4446B039.9000806@columbia.edu> from "Jeffrey Altman" at Apr 19, 6 05:48:41 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: kitten@lists.ietf.org Subject: Re: Working Group Last Call (Take Two): Desired Enhancements to GSSAPI X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org Jeffrey Altman wrote: > > This note announces the start of a two week working group last call > for the Kitten work item "Desired Enhancements to GSSAPI Naming". > http://www.ietf.org/internet-drafts/draft-ietf-kitten-gss-naming-04..txt One thing that hasn't be addressed, but which is probably an issue (in particular with the IESG...): I18N. The C-Bindings document mentions at one place that printable strings use the ISO Latin 1 codepage, but what actual implementations of GSS-API mechanism really use (and what applications expect) varies. e.g. we do ship our application (and a particular oem library with a gssapi mechanism) for two native EBCDIC platforms (OS/390 and OS/400), and both use an EBCDIC codepage for the printables -- which differs from ISO Latin 1 even for 7-bit ASCII (IA5) characters. Even for language bindings that natively support Unicode (like Java), the use of non-ASCII characters in the underlying GSS-API mechanism may create interoperability problems, i.e. with Kerberos 5 principal names and rfc1510 communication peers. It might be a good idea if a gssapi mechanism and an application caller (of the GSS-API C-Bindings) could agree on (or negotiate) the use of UTF8-strings for printables instead of the currently defined ISO-Latin-1 per rfc-2744 and the (de-facto) implementation defined behaviour of exisiting implementations. Supporting UTF-8 for printables (and have mechanism and application negotiate or agree upon this) will usually require code changes in both. I may be forced to implement a proprietary extension for interoperabitity of third-party gssapi libraries with our application through an additional API call (for "negotiating" the use of UTF-8 for printables) for our east european and asian customers. The use of non-ASCII and non-ISO-Latin-1 characters within Subject DNames of X.509 certs is quite popular there and so is the use of SPKM or SPKM-like gssapi mechanisms for Single Sign-On. printable strings are "names" as input parameter to gss_import_name() and output parameter from gss_display_name() as well as the textual representations of minor and major status codes as returned from gss_display_status(). Thoughts? Experiences? Has anyone else encountered I18N issues with GSS-API (C-Bindings) or already devised a solution? What codepage does your (gss-api) implementation use or your application expect/use? AFAIK MIT Kerberos 5 has traditionally use the "just send 8(-bit)" not just on the network, but also at the (GSS-)API. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Fri Apr 21 18:04:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FX3jx-0002Hd-2K; Fri, 21 Apr 2006 18:04:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FX3jw-0002HY-8z for kitten@lists.ietf.org; Fri, 21 Apr 2006 18:04:36 -0400 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FX3jt-0002M1-Ml for kitten@lists.ietf.org; Fri, 21 Apr 2006 18:04:36 -0400 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id k3LM4WrM000121 for ; Fri, 21 Apr 2006 15:04:32 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id k3LM4Vdc024375 for ; Fri, 21 Apr 2006 16:04:32 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k3LM4Vp7002902; Fri, 21 Apr 2006 17:04:31 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k3LM4UCS002901; Fri, 21 Apr 2006 17:04:30 -0500 (CDT) Date: Fri, 21 Apr 2006 17:04:30 -0500 From: Nicolas Williams To: Martin Rex Message-ID: <20060421220430.GK1074@binky.Central.Sun.COM> Mail-Followup-To: Martin Rex , Jeffrey Altman , kitten@lists.ietf.org References: <4446B039.9000806@columbia.edu> <200604212123.XAA29342@uw1048.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200604212123.XAA29342@uw1048.wdf.sap.corp> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: kitten@lists.ietf.org Subject: Re: Working Group Last Call (Take Two): Desired Enhancements to GSSAPI X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Fri, Apr 21, 2006 at 11:23:46PM +0200, Martin Rex wrote: > Jeffrey Altman wrote: > > This note announces the start of a two week working group last call > > for the Kitten work item "Desired Enhancements to GSSAPI Naming". > > http://www.ietf.org/internet-drafts/draft-ietf-kitten-gss-naming-04..txt > > One thing that hasn't be addressed, but which is probably an > issue (in particular with the IESG...): I18N. That is orthogonal to the naming extensions work. > The C-Bindings document mentions at one place that printable strings > use the ISO Latin 1 codepage, but what actual implementations of > GSS-API mechanism really use (and what applications expect) > varies. Typically they use whatever the current locale demands, which is what RFC2744 should have said all along. > e.g. we do ship our application (and a particular oem library with > a gssapi mechanism) for two native EBCDIC platforms (OS/390 and OS/400), > and both use an EBCDIC codepage for the printables -- which differs > from ISO Latin 1 even for 7-bit ASCII (IA5) characters. > > Even for language bindings that natively support Unicode (like Java), > the use of non-ASCII characters in the underlying GSS-API mechanism > may create interoperability problems, i.e. with Kerberos 5 principal > names and rfc1510 communication peers. This is a mechanism-specific issue. > It might be a good idea if a gssapi mechanism and an application caller > (of the GSS-API C-Bindings) could agree on (or negotiate) the use of > UTF8-strings for printables instead of the currently defined > ISO-Latin-1 per rfc-2744 and the (de-facto) implementation defined > behaviour of exisiting implementations. IMO this way lies madness -- it makes the GSS-API not so generic. I believe applications and the GSS-API functions that receive text inputs or which produce text outputs should use the current locale and nothing but. We may want new major status codes to indicate codeset conversion issues, but we can always get by with minor status codes. Mechanisms should do, in their tokens and protocols, whatever their specifications say, converting to/from the application locale as necessary. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Sat Apr 22 17:53:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXQ2s-0004jl-0y; Sat, 22 Apr 2006 17:53:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXQ2q-0004jg-7F for kitten@lists.ietf.org; Sat, 22 Apr 2006 17:53:36 -0400 Received: from stratton-five-eighty-two.mit.edu ([18.187.7.71] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FXQ2o-0007wX-Ul for kitten@lists.ietf.org; Sat, 22 Apr 2006 17:53:36 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id A2F63E0004; Sat, 22 Apr 2006 17:53:28 -0400 (EDT) To: martin.rex@sap.com References: <200604212123.XAA29342@uw1048.wdf.sap.corp> From: Sam Hartman Date: Sat, 22 Apr 2006 17:53:28 -0400 In-Reply-To: <200604212123.XAA29342@uw1048.wdf.sap.corp> (Martin Rex's message of "Fri, 21 Apr 2006 23:23:46 +0200 (MET DST)") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: kitten@lists.ietf.org Subject: Re: Working Group Last Call (Take Two): Desired Enhancements to GSSAPI X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org >>>>> "Martin" == Martin Rex writes: Martin> Jeffrey Altman wrote: >> This note announces the start of a two week working group last >> call for the Kitten work item "Desired Enhancements to GSSAPI >> Naming". >> http://www.ietf.org/internet-drafts/draft-ietf-kitten-gss-naming-04..txt Martin> One thing that hasn't be addressed, but which is probably Martin> an issue (in particular with the IESG...): I18N. Martin> The C-Bindings document mentions at one place that Martin> printable strings use the ISO Latin 1 codepage, but what Martin> actual implementations of GSS-API mechanism really use Martin> (and what applications expect) varies. Good point. Martin> e.g. we do ship our application (and a particular oem Martin> library with a gssapi mechanism) for two native EBCDIC Martin> platforms (OS/390 and OS/400), and both use an EBCDIC Martin> codepage for the printables -- which differs from ISO Martin> Latin 1 even for 7-bit ASCII (IA5) characters. Martin> Even for language bindings that natively support Unicode Martin> (like Java), the use of non-ASCII characters in the Martin> underlying GSS-API mechanism may create interoperability Martin> problems, i.e. with Kerberos 5 principal names and rfc1510 Martin> communication peers. Martin> It might be a good idea if a gssapi mechanism and an Martin> application caller (of the GSS-API C-Bindings) could agree Martin> on (or negotiate) the use of UTF8-strings for printables Martin> instead of the currently defined ISO-Latin-1 per rfc-2744 Martin> and the (de-facto) implementation defined behaviour of Martin> exisiting implementations. Martin> Thoughts? Experiences? Martin> Has anyone else encountered I18N issues with GSS-API Martin> (C-Bindings) or already devised a solution? What codepage Martin> does your (gss-api) implementation use or your application Martin> expect/use? We have encountered issues but have not managed to solve them. I don't think we can propose specific solutions in this draft basically because I don't think we have them yet, and I don't want to hold up this draft. I do think we can add a section describing the problem and claiming it needs to be solved. I will post text shortly. Assuming there are not other issues I'd prefer to last call that text but not re last call the entire document. --Sam _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Sat Apr 22 18:25:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXQXL-0002rL-RZ; Sat, 22 Apr 2006 18:25:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXQXK-0002rG-7W for kitten@lists.ietf.org; Sat, 22 Apr 2006 18:25:06 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FXQXI-0000Ym-03 for kitten@lists.ietf.org; Sat, 22 Apr 2006 18:25:06 -0400 Received: from [192.168.1.13] (cpe-68-175-91-105.nyc.res.rr.com [68.175.91.105]) (user=jaltman mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.6/8.13.6) with ESMTP id k3MMOu7C027327 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 22 Apr 2006 18:24:57 -0400 (EDT) Message-ID: <444AADD5.5030408@columbia.edu> Date: Sat, 22 Apr 2006 18:27:33 -0400 From: Jeffrey Altman Organization: No Longer Affiliated with Columbia University in the City of New York User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Sam Hartman References: <200604212123.XAA29342@uw1048.wdf.sap.corp> In-Reply-To: X-Enigmail-Version: 0.94.0.0 X-Enigmail-Version: 0.94.0.0 X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: kitten@lists.ietf.org Subject: Re: Working Group Last Call (Take Two): Desired Enhancements to GSSAPI X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1431858331==" Errors-To: kitten-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============1431858331== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020702070400070403080204" This is a cryptographically signed message in MIME format. --------------ms020702070400070403080204 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sam Hartman wrote: > Martin> Has anyone else encountered I18N issues with GSS-API > Martin> (C-Bindings) or already devised a solution? What codepage > Martin> does your (gss-api) implementation use or your application > Martin> expect/use? > > We have encountered issues but have not managed to solve them. > > I don't think we can propose specific solutions in this draft > basically because I don't think we have them yet, and I don't want to > hold up this draft. I do think we can add a section describing the > problem and claiming it needs to be solved. I will post text shortly. > Assuming there are not other issues I'd prefer to last call that text > but not re last call the entire document. > > --Sam Speaking as Chair, I would be happy to consider a separate WGLC on just a new section of text. Speaking as an Individual, I wonder whether Internationalization of GSS-API should be considered part of the Naming draft. It clearly is a problem that needs to be solved but it is not in the same category of scope definition that the rest of this draft attempts to provide. Jeffrey Altman --------------ms020702070400070403080204 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJPzCC AvowggJjoAMCAQICAw7NrDANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUwNTI3MTc0MjQzWhcNMDYwNTI3MTc0MjQz WjBrMQ8wDQYDVQQEEwZBbHRtYW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMT SmVmZnJleSBFcmljIEFsdG1hbjEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBjb2x1bWJpYS5l ZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+LutDu/YyHreNfoYd+ZtOjXsL h67F2cmcVuBPBz+ZGDA+WpVEHrqXaZZO8acXBR5uAVfiwA1acE/kvD/CN5kAqx1VJuQ8Pvyk iGHhUYTd27ZTliBIrptC7C/381gVwkS+a8jQFPJPO+OktZDzAYplGRY/MQCV8dIsvXUjucox 7TwTTdoLAJYRvHtfEcaCc6mO4ph6NeXQw8Grlx3IRAlTrkE5fBGyjH6R4fqnFTXRQAh1/bG+ i8hQvE6mud3mXdL2t7NP1Qxd9wW0/F/pnWY12IFP/luc3zEzIPvAe+nJluLuSEj0LZgP16mF xBj1p+u9HPWcHRVX6q7+MQ0RWOv1AgMBAAGjMTAvMB8GA1UdEQQYMBaBFGphbHRtYW5AY29s dW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAUDUuzxiq8bbI8vq2 swRK513RphZp+fepyKU5mwBI6aF4GcmqITQILtfTG2SXnjSeY99d+bjOdK1DJFvVh9aOy8mh 2NbEnqMnJIZtg5+eEU64DIV5bQdDRpi99H9vA0sRATIquut+3YHba+zArj0VkVof2VI+ToBu sHdtSrZYo0gwggL6MIICY6ADAgECAgMOzawwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA1MDUyNzE3NDI0M1oXDTA2 MDUyNzE3NDI0M1owazEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMx HDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xIzAhBgkqhkiG9w0BCQEWFGphbHRtYW5A Y29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvi7rQ7v2Mh63 jX6GHfmbTo17C4euxdnJnFbgTwc/mRgwPlqVRB66l2mWTvGnFwUebgFX4sANWnBP5Lw/wjeZ AKsdVSbkPD78pIhh4VGE3du2U5YgSK6bQuwv9/NYFcJEvmvI0BTyTzvjpLWQ8wGKZRkWPzEA lfHSLL11I7nKMe08E03aCwCWEbx7XxHGgnOpjuKYejXl0MPBq5cdyEQJU65BOXwRsox+keH6 pxU10UAIdf2xvovIULxOprnd5l3S9rezT9UMXfcFtPxf6Z1mNdiBT/5bnN8xMyD7wHvpyZbi 7khI9C2YD9ephcQY9afrvRz1nB0VV+qu/jENEVjr9QIDAQABozEwLzAfBgNVHREEGDAWgRRq YWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAFA1 Ls8YqvG2yPL6trMESudd0aYWafn3qcilOZsASOmheBnJqiE0CC7X0xtkl540nmPfXfm4znSt QyRb1YfWjsvJodjWxJ6jJySGbYOfnhFOuAyFeW0HQ0aYvfR/bwNLEQEyKrrrft2B22vswK49 FZFaH9lSPk6AbrB3bUq2WKNIMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAzswggM3AgEB MGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMOzaww CQYFKw4DAhoFAKCCAacwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMDYwNDIyMjIyNzMzWjAjBgkqhkiG9w0BCQQxFgQUuXAjJGixKg1QYlJhOWj1RNmkfRQw UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw7NrDB6BgsqhkiG9w0B CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AgMOzawwDQYJKoZIhvcNAQEBBQAEggEAA6GzaHAExtUeAFOkQSqO8AgAAa0gS6gnu2NqINvq lTqR2fgxG3ZTgcFeY+mGDhdrY3f1EQvcqD0CEHkB9uJRx/UD3LK/vPTsBDDmb9s2Qo3aQQAX HQxAiOGfMRb+i3kiMZbcBLUd3Of1dGu94O3SqTX2mtSbYsWDGHJQ4NGOMXFqchrz+SRI+MIE I/c/lf+M773ip8tIv12TI5FkQuBeP8wf27ggXFI8HyPr7bGqKV/Ew0W6XAPxaLOazGVo7sd9 3uFv7mIvaMy7hs2S3L45ulBSF4s4p7UWv3mGAKh33L/OO7ifhqTpNEl6bhGn/+0anl8U7WH2 QnBhHg6I32W9NgAAAAAAAA== --------------ms020702070400070403080204-- --===============1431858331== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten --===============1431858331==-- From kitten-bounces@lists.ietf.org Mon Apr 24 12:18:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY3lv-0003AE-QQ; Mon, 24 Apr 2006 12:18:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY3lu-0003A8-O5 for kitten@lists.ietf.org; Mon, 24 Apr 2006 12:18:46 -0400 Received: from crunchberry.srv.cs.cmu.edu ([128.2.203.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FY3lu-0004KJ-Eb for kitten@lists.ietf.org; Mon, 24 Apr 2006 12:18:46 -0400 Received: from sirius.fac.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by crunchberry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id k3OGIhaH025891 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Apr 2006 12:18:44 -0400 (EDT) Date: Mon, 24 Apr 2006 12:18:43 -0400 From: Jeffrey Hutzelman To: Nicolas Williams , Martin Rex Message-ID: In-Reply-To: <20060421220430.GK1074@binky.Central.Sun.COM> References: <4446B039.9000806@columbia.edu> <200604212123.XAA29342@uw1048.wdf.sap.corp> <20060421220430.GK1074@binky.Central.Sun.COM> Originator-Info: login-token=Mulberry:01uB0Z3yKFjlMEaJFg65tJTk+PUAo/UZIlkkdE7p0=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: kitten@lists.ietf.org Subject: Re: Working Group Last Call (Take Two): Desired Enhancements to GSSAPI X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Friday, April 21, 2006 05:04:30 PM -0500 Nicolas Williams wrote: > Typically they use whatever the current locale demands, which is what > RFC2744 should have said all along. Agree, to a point. > I believe applications and the GSS-API functions that receive text > inputs or which produce text outputs should use the current locale and > nothing but. For the exsting API functions, I agree. However, I would not be opposed to defining an alternate set of interfaces which use UTF-8 for all text, allowing the application to fully take charge of locale issues. If the only API available is one that depends on the current locale, then it is impossible for an application to receive names from the GSSAPI which contain characters not in the local character set, even if both the application and the underlying mechanism support such names. Since in the IETF we have for some time been encouraging (requiring) application protocols to use UTF-8, it would seem to maek sense to make it possible for implementations of GSSAPI-using protocols to do so in a portable way. > Mechanisms should do, in their tokens and protocols, whatever their > specifications say, converting to/from the application locale as > necessary. ... or to/from UTF-8, if that is the API in use. I agree with others who have suggested that this is a separate issue from naming extensions, and should be handled separately. -- Jeff _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Apr 24 12:31:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY3yH-0007fg-8t; Mon, 24 Apr 2006 12:31:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY3yG-0007fT-2B for kitten@lists.ietf.org; Mon, 24 Apr 2006 12:31:32 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FY3yC-0004rX-Hn for kitten@lists.ietf.org; Mon, 24 Apr 2006 12:31:32 -0400 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id k3OGVP8x015067 for ; Mon, 24 Apr 2006 10:31:25 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id k3OGVNdc007598 for ; Mon, 24 Apr 2006 10:31:25 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k3OGVK9W004026; Mon, 24 Apr 2006 11:31:20 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k3OGVJYj004025; Mon, 24 Apr 2006 11:31:19 -0500 (CDT) Date: Mon, 24 Apr 2006 11:31:19 -0500 From: Nicolas Williams To: Jeffrey Hutzelman Message-ID: <20060424163119.GA4000@binky.Central.Sun.COM> Mail-Followup-To: Jeffrey Hutzelman , Martin Rex , kitten@lists.ietf.org References: <4446B039.9000806@columbia.edu> <200604212123.XAA29342@uw1048.wdf.sap.corp> <20060421220430.GK1074@binky.Central.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: kitten@lists.ietf.org Subject: Re: Working Group Last Call (Take Two): Desired Enhancements to GSSAPI X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Mon, Apr 24, 2006 at 12:18:43PM -0400, Jeffrey Hutzelman wrote: > On Friday, April 21, 2006 05:04:30 PM -0500 Nicolas Williams > wrote: > > >Typically they use whatever the current locale demands, which is what > >RFC2744 should have said all along. > > Agree, to a point. > > >I believe applications and the GSS-API functions that receive text > >inputs or which produce text outputs should use the current locale and > >nothing but. > > For the exsting API functions, I agree. > However, I would not be opposed to defining an alternate set of interfaces > which use UTF-8 for all text, allowing the application to fully take charge > of locale issues. If the only API available is one that depends on the > current locale, then it is impossible for an application to receive names > from the GSSAPI which contain characters not in the local character set, > even if both the application and the underlying mechanism support such > names. Since in the IETF we have for some time been encouraging > (requiring) application protocols to use UTF-8, it would seem to maek sense > to make it possible for implementations of GSSAPI-using protocols to do so > in a portable way. Sure. > >Mechanisms should do, in their tokens and protocols, whatever their > >specifications say, converting to/from the application locale as > >necessary. > > ... or to/from UTF-8, if that is the API in use. > > I agree with others who have suggested that this is a separate issue from > naming extensions, and should be handled separately. I agree. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Apr 24 17:28:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY8bn-0007S9-27; Mon, 24 Apr 2006 17:28:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY8bl-0007S4-Vv for kitten@lists.ietf.org; Mon, 24 Apr 2006 17:28:37 -0400 Received: from carter-zimmerman.dyn.mit.edu ([18.188.3.148] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FY8bk-00047f-3h for kitten@lists.ietf.org; Mon, 24 Apr 2006 17:28:37 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 61841E0053; Mon, 24 Apr 2006 17:28:29 -0400 (EDT) To: Jeffrey Hutzelman References: <4446B039.9000806@columbia.edu> <200604212123.XAA29342@uw1048.wdf.sap.corp> <20060421220430.GK1074@binky.Central.Sun.COM> From: Sam Hartman Date: Mon, 24 Apr 2006 17:28:29 -0400 In-Reply-To: (Jeffrey Hutzelman's message of "Mon, 24 Apr 2006 12:18:43 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: Nicolas Williams , kitten@lists.ietf.org Subject: Internationalization X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org >>>>> "Jeffrey" == Jeffrey Hutzelman writes: Jeffrey> On Friday, April 21, 2006 05:04:30 PM -0500 Nicolas Jeffrey> Williams Jeffrey> wrote: >> Typically they use whatever the current locale demands, which >> is what RFC2744 should have said all along. Jeffrey> Agree, to a point. >> I believe applications and the GSS-API functions that receive >> text inputs or which produce text outputs should use the >> current locale and nothing but. Jeffrey> For the exsting API functions, I agree. However, I would Jeffrey> not be opposed to defining an alternate set of interfaces Jeffrey> which use UTF-8 for all text, allowing the application to Jeffrey> fully take charge of locale issues. If the only API Jeffrey> available is one that depends on the current locale, then Jeffrey> it is impossible for an application to receive names from Jeffrey> the GSSAPI which contain characters not in the local Jeffrey> character set, even if both the application and the Jeffrey> underlying mechanism support such names. Since in the Jeffrey> IETF we have for some time been encouraging (requiring) Jeffrey> application protocols to use UTF-8, it would seem to maek Jeffrey> sense to make it possible for implementations of Jeffrey> GSSAPI-using protocols to do so in a portable way. I wonder if the right way to do this is to create new OIDs for UTF8 variants of name types? This is very half-baked. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Apr 24 17:40:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY8mg-0001vU-72; Mon, 24 Apr 2006 17:39:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY8me-0001vM-7l for kitten@lists.ietf.org; Mon, 24 Apr 2006 17:39:52 -0400 Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FY8md-0004dx-1o for kitten@lists.ietf.org; Mon, 24 Apr 2006 17:39:52 -0400 Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa05085; 24 Apr 2006 17:39 EDT Date: Mon, 24 Apr 2006 17:39:14 -0400 (EDT) From: Jeffrey Hutzelman X-X-Sender: To: Sam Hartman In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Nicolas Williams , kitten@lists.ietf.org Subject: Re: Internationalization X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Mon, 24 Apr 2006, Sam Hartman wrote: > I wonder if the right way to do this is to create new OIDs for UTF8 > variants of name types? I don't think so, because I think there are cases where you'll expect a name to retain the same type end-to-end, and I think the question of whether to use a locale-based API or a UTF-8-based one is at least partly a matter for the application implementation. But I could be wrong; I haven't thought about this idea more than you have. -- Jeff _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Apr 24 17:51:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY8xm-0007op-7P; Mon, 24 Apr 2006 17:51:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY8xl-0007ok-AM for kitten@lists.ietf.org; Mon, 24 Apr 2006 17:51:21 -0400 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FY8xk-0005GV-Rm for kitten@lists.ietf.org; Mon, 24 Apr 2006 17:51:21 -0400 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id XAA05080; Mon, 24 Apr 2006 23:51:02 +0200 (MESZ) From: Martin Rex Message-Id: <200604242151.XAA18890@uw1048.wdf.sap.corp> To: hartmans-ietf@mit.edu (Sam Hartman) Date: Mon, 24 Apr 2006 23:51:02 +0200 (MET DST) In-Reply-To: from "Sam Hartman" at Apr 24, 6 05:28:29 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: kitten@lists.ietf.org, Nicolas.Williams@sun.com Subject: Re: Internationalization X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org Sam Hartman wrote: > > >>>>> "Jeffrey" == Jeffrey Hutzelman writes: > > Jeffrey> On Friday, April 21, 2006 05:04:30 PM -0500 Nicolas > Jeffrey> Williams > Jeffrey> wrote: > > >> Typically they use whatever the current locale demands, which > >> is what RFC2744 should have said all along. > > Jeffrey> Agree, to a point. > > > > >> I believe applications and the GSS-API functions that receive > >> text inputs or which produce text outputs should use the > >> current locale and nothing but. > > Jeffrey> For the exsting API functions, I agree. However, I would > Jeffrey> not be opposed to defining an alternate set of interfaces > Jeffrey> which use UTF-8 for all text, allowing the application to > Jeffrey> fully take charge of locale issues. If the only API > Jeffrey> available is one that depends on the current locale, then > Jeffrey> it is impossible for an application to receive names from > Jeffrey> the GSSAPI which contain characters not in the local > Jeffrey> character set, even if both the application and the > Jeffrey> underlying mechanism support such names. Since in the > Jeffrey> IETF we have for some time been encouraging (requiring) > Jeffrey> application protocols to use UTF-8, it would seem to maek > Jeffrey> sense to make it possible for implementations of > Jeffrey> GSSAPI-using protocols to do so in a portable way. > > > I wonder if the right way to do this is to create new OIDs for UTF8 > variants of name types? For the input, it would be easy and straight-forward to create seperate nametypes that indicate UTF-8 encoding. However this does not address/solve 2 remaining issues: - what about gss_display_name() -- where the gssapi mechanism has to decide which nametype to emit and the use of an UTF-8 implying nametype is a change that might upset/confuse non-UTF-8-aware callers - what about the printables returned from gss_display_status(), where one can not overload an accompanying nametype with character encoding (codepage) I really dislike the idea of using the "locale". While it might be OK to some extent to influence the textual messages returned from gss_display_name(), I would consider it a real problem for the purpose of names. Names are supposed to be unique, and I have a real problem if changing the locale would also cause an authentication of one principal match for the ACL entry of another one. Remember, the original GSS-API v1 suggested to perform authentication based on printable names (only) -- binary canonical names (which are hopefully immune to locales even for Nico's gssapi implementations) were invented for GSS-API v2 because *we* desperately needed them. :) Still, the target name for the mutual authentication is normally derived from a printable (on the initator side), even with ACLs containing binary canonical names at the acceptor side. I also do not want a change in the locale to mess up the generation of ACLs containing binary canonical names from admin/human-maintained printable originals. -Martin > > > > This is very half-baked. > > _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Apr 24 17:53:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY8zn-0008RW-KL; Mon, 24 Apr 2006 17:53:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY8zm-0008RR-Hd for kitten@lists.ietf.org; Mon, 24 Apr 2006 17:53:26 -0400 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FY8zk-0005Ki-1E for kitten@lists.ietf.org; Mon, 24 Apr 2006 17:53:26 -0400 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id k3OLrMrM007995 for ; Mon, 24 Apr 2006 14:53:23 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id k3OLrLcc010646 for ; Mon, 24 Apr 2006 15:53:22 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k3OLrLhp004280; Mon, 24 Apr 2006 16:53:21 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k3OLrIt3004279; Mon, 24 Apr 2006 16:53:18 -0500 (CDT) Date: Mon, 24 Apr 2006 16:53:18 -0500 From: Nicolas Williams To: Sam Hartman Message-ID: <20060424215318.GG4000@binky.Central.Sun.COM> Mail-Followup-To: Sam Hartman , Jeffrey Hutzelman , Martin Rex , kitten@lists.ietf.org References: <4446B039.9000806@columbia.edu> <200604212123.XAA29342@uw1048.wdf.sap.corp> <20060421220430.GK1074@binky.Central.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: kitten@lists.ietf.org Subject: Re: Internationalization X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Mon, Apr 24, 2006 at 05:28:29PM -0400, Sam Hartman wrote: > I wonder if the right way to do this is to create new OIDs for UTF8 > variants of name types? That would work for GSS_Import_name(). What about GSS_Display_name() and GSS_Display_status()? IF we can't rely on the current locale using Unicode THEN we need new functions, IMO. However, I suspect we (OS vendors) are all moving towards UTF-8 locales anyways, which would tend to make this matter moot. As an implementor I find it a lot easier to push users to use UTF-8 locales and put conversions wherever they are necessary. Sometimes one has no choice. E.g., filesystem I18N, where we (Sun) will be pursuing a convention where all path/component names between the syscall layer and the VFS are assumed to be in UTF-8 -- userland will get pushed to use UTF-8 locales and perhaps we'll have libc syscall stubs do codeset conversions for legacy locales, while filesystem modules will be able to do their own conversions (e.g., to UTF-16) and optionally (but by default?) reject malformed inputs. In the GSS-API case we could add convenience extensions that explicitly use UTF-8, but this wouldn't deal with legacy applications; the only way to deal with those is what pretty much all implementors do: assume the current locale's codeset and convert where necessary -- this seems to work well enough, so why bother adding new interfaces? Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Apr 24 18:03:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY99O-0001iO-NZ; Mon, 24 Apr 2006 18:03:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY99N-0001iI-7u for kitten@lists.ietf.org; Mon, 24 Apr 2006 18:03:21 -0400 Received: from carter-zimmerman.dyn.mit.edu ([18.188.3.148] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FY99M-0005yk-1t for kitten@lists.ietf.org; Mon, 24 Apr 2006 18:03:21 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 68734E0053; Mon, 24 Apr 2006 18:03:13 -0400 (EDT) To: Jeffrey Hutzelman References: From: Sam Hartman Date: Mon, 24 Apr 2006 18:03:13 -0400 In-Reply-To: (Jeffrey Hutzelman's message of "Mon, 24 Apr 2006 17:39:14 -0400 (EDT)") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: kitten@lists.ietf.org, Nicolas Williams Subject: Re: Internationalization X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org >>>>> "Jeffrey" == Jeffrey Hutzelman writes: Jeffrey> On Mon, 24 Apr 2006, Sam Hartman wrote: >> I wonder if the right way to do this is to create new OIDs for >> UTF8 variants of name types? Jeffrey> I don't think so, because I think there are cases where Jeffrey> you'll expect a name to retain the same type end-to-end, Jeffrey> and I think the question of whether to use a locale-based Jeffrey> API or a UTF-8-based one is at least partly a matter for Jeffrey> the application implementation. Jeffrey> But I could be wrong; I haven't thought about this idea Jeffrey> more than you have. I think the display name issue is a huge problem with my proposal. However I do believe that there is no expectation that names will retain the same type end-to-end. Consider for example the fact that user name types typically become MNs. There are issues having to do with ACLs which Martin points out, but that is weaker than what you cleam. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Apr 24 18:25:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY9UK-0005F3-6A; Mon, 24 Apr 2006 18:25:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY9UC-00054k-Oo for kitten@lists.ietf.org; Mon, 24 Apr 2006 18:24:52 -0400 Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FY9Gz-0006j5-SI for kitten@lists.ietf.org; Mon, 24 Apr 2006 18:11:15 -0400 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id AAA17232; Tue, 25 Apr 2006 00:10:55 +0200 (MESZ) From: Martin Rex Message-Id: <200604242210.AAA19356@uw1048.wdf.sap.corp> To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Tue, 25 Apr 2006 00:10:53 +0200 (MET DST) In-Reply-To: <20060424215318.GG4000@binky.Central.Sun.COM> from "Nicolas Williams" at Apr 24, 6 04:53:18 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: hartmans-ietf@mit.edu, kitten@lists.ietf.org Subject: Re: Internationalization X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org Nicolas Williams wrote: > > IF we can't rely on the current locale using Unicode THEN we need new > functions, IMO. Thinking about it, that actually seems to be the most fool-proof approach for migrating existing installations. > > However, I suspect we (OS vendors) are all moving towards UTF-8 > locales anyways, which would tend to make this matter moot. > > As an implementor I find it a lot easier to push users to use UTF-8 > locales and put conversions wherever they are necessary. I will have to support all of the existing installations in the fashion in which they now (sometimes by mere chance) work in customer installations, and I will have to provide a migration path to utf-8 aware interoperability independent of locale in the future -- and gracefully deal with every conceivable mix of now and then gss-api implementations and applications. Currently, neither gss-api mechanism nor application knows or has a way to figure out which locales are supported by the other and really, I consider it a security problem when the representation of a name, as it appears on an ACL changes when changing the locale! There may be an extremely low risk with names from the ASCII character set to be confused, but I do have a very bad feeling about the non-ascii codepages (and they're the reason why we're looking into this). -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Apr 24 18:26:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY9VO-0005va-JJ; Mon, 24 Apr 2006 18:26:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY9U9-000547-Vo for kitten@lists.ietf.org; Mon, 24 Apr 2006 18:24:49 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FY9Ox-0007In-5w for kitten@lists.ietf.org; Mon, 24 Apr 2006 18:19:28 -0400 Received: from centralmail2brm.Central.Sun.COM (centralmail2brm.central.sun.com [129.147.62.14]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id k3OMJQaN024515 for ; Mon, 24 Apr 2006 16:19:26 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id k3OMJPdc013306 for ; Mon, 24 Apr 2006 16:19:26 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k3OMJPcK004372; Mon, 24 Apr 2006 17:19:25 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k3OMJPCS004371; Mon, 24 Apr 2006 17:19:25 -0500 (CDT) Date: Mon, 24 Apr 2006 17:19:25 -0500 From: Nicolas Williams To: Martin Rex Message-ID: <20060424221924.GJ4000@binky.Central.Sun.COM> Mail-Followup-To: Martin Rex , hartmans-ietf@mit.edu, jhutz@cmu.edu, kitten@lists.ietf.org References: <20060424215318.GG4000@binky.Central.Sun.COM> <200604242210.AAA19356@uw1048.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200604242210.AAA19356@uw1048.wdf.sap.corp> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: hartmans-ietf@mit.edu, kitten@lists.ietf.org Subject: Re: Internationalization X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Tue, Apr 25, 2006 at 12:10:53AM +0200, Martin Rex wrote: > Nicolas Williams wrote: > > > > IF we can't rely on the current locale using Unicode THEN we need new > > functions, IMO. > > Thinking about it, that actually seems to be the most fool-proof > approach for migrating existing installations. We agree. Interesting ;) > > > > However, I suspect we (OS vendors) are all moving towards UTF-8 > > locales anyways, which would tend to make this matter moot. > > > > As an implementor I find it a lot easier to push users to use UTF-8 > > locales and put conversions wherever they are necessary. > > I will have to support all of the existing installations in the > fashion in which they now (sometimes by mere chance) work in ^^^^^^^^^^^^^^^^^^^^^^^^ Yes, the joys of just-use-8/just-send-8/just-dont-normalize. > customer installations, and I will have to provide a migration > path to utf-8 aware interoperability independent of locale > in the future -- and gracefully deal with every conceivable > mix of now and then gss-api implementations and applications. I think in the Unix world the trend will be to UTF-8 locales. That should help. I think app vendors should seriously think about requiring the use of UTF-8 locales. Of course, merely expecting that use of UTF-8 locales solves all problems only "improves" the situation from a that-really-really-sucks world of just-use-8 to a that-just-sucks world of just-dont-normalize. Normalization (and stringprep profiling!) matters. Fortunately as far as the KITTEN WG is concerned codeset conversion, normalization and stringprep profiles are ALL mechanism-specific matters (provided we fix RFC2744 to say "current locale's codeset" instead of "Latin-1;" it helps that this is the only reasonable thing to do). > Currently, neither gss-api mechanism nor application knows or > has a way to figure out which locales are supported by the other > and really, I consider it a security problem when the representation > of a name, as it appears on an ACL changes when changing the locale! Mechanisms need to specify this. Kerberos V does (currently: printable US-ASCII; soon full I18N based on UTF-8 and stringprep profiling). > There may be an extremely low risk with names from the ASCII > character set to be confused, but I do have a very bad feeling > about the non-ascii codepages (and they're the reason why > we're looking into this). Confusables? Let's not go there. This is the KITTEN WG :) Go check the SAAG archives if you really want to have fun with confusables. Cheers, Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Apr 26 17:18:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYrOu-00072C-UM; Wed, 26 Apr 2006 17:18:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYrOt-000727-TZ for kitten@ietf.org; Wed, 26 Apr 2006 17:18:19 -0400 Received: from carter-zimmerman.dyn.mit.edu ([18.188.3.148] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYrOs-0006FQ-OF for kitten@ietf.org; Wed, 26 Apr 2006 17:18:19 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id B7706E006A; Wed, 26 Apr 2006 17:18:02 -0400 (EDT) To: kitten@ietf.org From: Sam Hartman Date: Wed, 26 Apr 2006 17:18:02 -0400 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: Subject: internationalization and the naming draft X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org Hi. A few people have said that they do not believe a discussion of internationalization belongs in my naming drfat. I'm OK with that, so unless instructed to do so by Jeff I will not propose text. I do think the issue is very important and will continue to participate in the discussion. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Apr 26 17:20:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYrQt-0007eh-Ao; Wed, 26 Apr 2006 17:20:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYrQs-0007bi-6z for kitten@ietf.org; Wed, 26 Apr 2006 17:20:22 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYrQs-0006KP-5P for kitten@ietf.org; Wed, 26 Apr 2006 17:20:22 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FYrQg-0002bt-7D for kitten@ietf.org; Wed, 26 Apr 2006 17:20:13 -0400 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id k3QLK98x011326 for ; Wed, 26 Apr 2006 15:20:09 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id k3QLK8da003003 for ; Wed, 26 Apr 2006 15:20:09 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k3QLK8kP008745; Wed, 26 Apr 2006 16:20:08 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k3QLK7dj008744; Wed, 26 Apr 2006 16:20:07 -0500 (CDT) Date: Wed, 26 Apr 2006 16:20:07 -0500 From: Nicolas Williams To: Sam Hartman Message-ID: <20060426212007.GL8152@binky.Central.Sun.COM> Mail-Followup-To: Sam Hartman , kitten@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: -2.6 (--) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: kitten@ietf.org Subject: Re: internationalization and the naming draft X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Wed, Apr 26, 2006 at 05:18:02PM -0400, Sam Hartman wrote: > I do think the issue is very important and will continue to > participate in the discussion. I agree, it's important, but orthogonal to your I-D. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Apr 26 17:34:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYrec-0002ql-5k; Wed, 26 Apr 2006 17:34:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYreb-0002qg-Eu for kitten@ietf.org; Wed, 26 Apr 2006 17:34:33 -0400 Received: from carter-zimmerman.dyn.mit.edu ([18.188.3.148] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYrea-0007My-9B for kitten@ietf.org; Wed, 26 Apr 2006 17:34:33 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 63589E0053; Wed, 26 Apr 2006 17:34:20 -0400 (EDT) To: kitten@ietf.org From: Sam Hartman Date: Wed, 26 Apr 2006 17:34:20 -0400 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Subject: Charter: internationalization is out of scope X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org Jeff Altman asked me a question about the charter and internationalization. Looking at your charter, internationalization is currently out of scope. I'd be happy to take a proposal to extend the charter to include internationalization to the IESG; I do not anticipate approvalbeing hard. Note that if the WG does not work on internationalization, you will likely have trouble getting API drafts approved because they will not meet IETF internationalization requirements. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Apr 26 17:35:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYrfc-0003Ax-Ie; Wed, 26 Apr 2006 17:35:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYrfb-0003AP-1X for kitten@ietf.org; Wed, 26 Apr 2006 17:35:35 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYrfZ-0007Uv-Qu for kitten@ietf.org; Wed, 26 Apr 2006 17:35:35 -0400 Received: from [192.168.1.13] (cpe-68-175-91-105.nyc.res.rr.com [68.175.91.105]) (user=jaltman mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.6/8.13.6) with ESMTP id k3QLZUK9004592 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 26 Apr 2006 17:35:31 -0400 (EDT) Message-ID: <444FE840.8050909@columbia.edu> Date: Wed, 26 Apr 2006 17:38:08 -0400 From: Jeffrey Altman Organization: No Longer Affiliated with Columbia University in the City of New York User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Sam Hartman , kitten@ietf.org References: <20060426212007.GL8152@binky.Central.Sun.COM> In-Reply-To: <20060426212007.GL8152@binky.Central.Sun.COM> X-Enigmail-Version: 0.94.0.0 X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: Subject: Re: internationalization and the naming draft X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0194860704==" Errors-To: kitten-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============0194860704== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090601040800020104070005" This is a cryptographically signed message in MIME format. --------------ms090601040800020104070005 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Nicolas Williams wrote: > On Wed, Apr 26, 2006 at 05:18:02PM -0400, Sam Hartman wrote: >> I do think the issue is very important and will continue to >> participate in the discussion. > > I agree, it's important, but orthogonal to your I-D. > > Nico Speaking as chair: Unless I hear a strong argument for why the naming problem space cannot be described without including a description of the internationalization problem and support for that argument I am going to allow the working group last call to complete without its inclusion. I will be doing so for two reasons: (1) there appears to be rough consensus that the problems are linked in such a way that naming cannot be described without a solution to the internationalization of GSS-API. (2) internationalization of GSS-API is currently not in the charter of this working group. I am not opposed to requesting that the group be re-chartered in order to address the problem but I would really like to see this group make some substantial progress on some of our existing work items before we begin to grapple with the internationalization problem. Jeffrey Altman --------------ms090601040800020104070005 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJPzCC AvowggJjoAMCAQICAw7NrDANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUwNTI3MTc0MjQzWhcNMDYwNTI3MTc0MjQz WjBrMQ8wDQYDVQQEEwZBbHRtYW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMT SmVmZnJleSBFcmljIEFsdG1hbjEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBjb2x1bWJpYS5l ZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+LutDu/YyHreNfoYd+ZtOjXsL h67F2cmcVuBPBz+ZGDA+WpVEHrqXaZZO8acXBR5uAVfiwA1acE/kvD/CN5kAqx1VJuQ8Pvyk iGHhUYTd27ZTliBIrptC7C/381gVwkS+a8jQFPJPO+OktZDzAYplGRY/MQCV8dIsvXUjucox 7TwTTdoLAJYRvHtfEcaCc6mO4ph6NeXQw8Grlx3IRAlTrkE5fBGyjH6R4fqnFTXRQAh1/bG+ i8hQvE6mud3mXdL2t7NP1Qxd9wW0/F/pnWY12IFP/luc3zEzIPvAe+nJluLuSEj0LZgP16mF xBj1p+u9HPWcHRVX6q7+MQ0RWOv1AgMBAAGjMTAvMB8GA1UdEQQYMBaBFGphbHRtYW5AY29s dW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAUDUuzxiq8bbI8vq2 swRK513RphZp+fepyKU5mwBI6aF4GcmqITQILtfTG2SXnjSeY99d+bjOdK1DJFvVh9aOy8mh 2NbEnqMnJIZtg5+eEU64DIV5bQdDRpi99H9vA0sRATIquut+3YHba+zArj0VkVof2VI+ToBu sHdtSrZYo0gwggL6MIICY6ADAgECAgMOzawwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA1MDUyNzE3NDI0M1oXDTA2 MDUyNzE3NDI0M1owazEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMx HDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xIzAhBgkqhkiG9w0BCQEWFGphbHRtYW5A Y29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvi7rQ7v2Mh63 jX6GHfmbTo17C4euxdnJnFbgTwc/mRgwPlqVRB66l2mWTvGnFwUebgFX4sANWnBP5Lw/wjeZ AKsdVSbkPD78pIhh4VGE3du2U5YgSK6bQuwv9/NYFcJEvmvI0BTyTzvjpLWQ8wGKZRkWPzEA lfHSLL11I7nKMe08E03aCwCWEbx7XxHGgnOpjuKYejXl0MPBq5cdyEQJU65BOXwRsox+keH6 pxU10UAIdf2xvovIULxOprnd5l3S9rezT9UMXfcFtPxf6Z1mNdiBT/5bnN8xMyD7wHvpyZbi 7khI9C2YD9ephcQY9afrvRz1nB0VV+qu/jENEVjr9QIDAQABozEwLzAfBgNVHREEGDAWgRRq YWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAFA1 Ls8YqvG2yPL6trMESudd0aYWafn3qcilOZsASOmheBnJqiE0CC7X0xtkl540nmPfXfm4znSt QyRb1YfWjsvJodjWxJ6jJySGbYOfnhFOuAyFeW0HQ0aYvfR/bwNLEQEyKrrrft2B22vswK49 FZFaH9lSPk6AbrB3bUq2WKNIMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAzswggM3AgEB MGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMOzaww CQYFKw4DAhoFAKCCAacwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMDYwNDI2MjEzODA4WjAjBgkqhkiG9w0BCQQxFgQUEM75fURjRp3qu6951wE+IBQckx8w UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw7NrDB6BgsqhkiG9w0B CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AgMOzawwDQYJKoZIhvcNAQEBBQAEggEAXtsXg/sbaJvLCV16V5cVxt25bWT8k1hcTGGmSZ0r Z9vlA6PdLGYXODBEAUq21QugWSaXdYJtEclM7ZVD4ZXaL5IOqJPGSSy9pFTbgk3Vaj/mGpAG kg6RDORynzBhATkcjOcki0za4sUllb3mRx8f+3AM10GBHIUVyKNhkX71IoXNNCI/U4VdusLn xgYMLJzoZFMAEaeXBgoGWtmWO4GzmvR5+NUZvXebgveoovpB7HzdBcKicgIYgjuYyDLQXN3+ Vutbq5NGH9FPaLjV2x1cbINnI3vR2z40otHQzxUF/cgNIUHBA+TxN8qsqC5gjajtTNh4iXqB YI5qecI5V8346gAAAAAAAA== --------------ms090601040800020104070005-- --===============0194860704== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten --===============0194860704==-- From kitten-bounces@lists.ietf.org Wed Apr 26 17:43:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYrnF-0001LV-FK; Wed, 26 Apr 2006 17:43:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYrnE-0001LQ-DX for kitten@ietf.org; Wed, 26 Apr 2006 17:43:28 -0400 Received: from biscayne-one-station.mit.edu ([18.7.7.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYrnD-0007rD-5o for kitten@ietf.org; Wed, 26 Apr 2006 17:43:28 -0400 Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id k3QLhGnp018331; Wed, 26 Apr 2006 17:43:26 -0400 (EDT) Received: from [18.101.0.231] ([18.101.0.231]) (authenticated bits=0) (User authenticated as raeburn@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id k3QLgqbb012094 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Wed, 26 Apr 2006 17:43:10 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: From: Ken Raeburn Date: Wed, 26 Apr 2006 17:42:50 -0400 To: Sam Hartman X-Mailer: Apple Mail (2.749.3) X-Spam-Score: 1.217 X-Spam-Level: * (1.217) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: kitten@ietf.org Subject: Re: Charter: internationalization is out of scope X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Apr 26, 2006, at 17:34, Sam Hartman wrote: > Note that if the WG does not work on internationalization, you will > likely have trouble getting API drafts approved because they will not > meet IETF internationalization requirements. If it's an IETF requirement, doesn't that implicitly put it in scope for any working group with a deliverable subject to that requirement, unless it's explicitly described as out of scope? Ken _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Apr 26 18:20:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYsNJ-0005ic-PE; Wed, 26 Apr 2006 18:20:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYsNI-0005iS-60 for kitten@ietf.org; Wed, 26 Apr 2006 18:20:44 -0400 Received: from nwkea-mail-5.sun.com ([192.18.42.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYsNG-0002Pv-LX for kitten@ietf.org; Wed, 26 Apr 2006 18:20:44 -0400 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-5.sun.com (8.12.10/8.12.9) with ESMTP id k3QMKfaN024809 for ; Wed, 26 Apr 2006 15:20:42 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id k3QMKddc009994 for ; Wed, 26 Apr 2006 16:20:40 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k3QMKYEH009504; Wed, 26 Apr 2006 17:20:34 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k3QMKXS5009503; Wed, 26 Apr 2006 17:20:33 -0500 (CDT) Date: Wed, 26 Apr 2006 17:20:33 -0500 From: Nicolas Williams To: Jeffrey Altman Message-ID: <20060426222033.GN8152@binky.Central.Sun.COM> Mail-Followup-To: Jeffrey Altman , Sam Hartman , kitten@ietf.org References: <20060426212007.GL8152@binky.Central.Sun.COM> <444FE840.8050909@columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <444FE840.8050909@columbia.edu> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: kitten@ietf.org, Sam Hartman Subject: Re: internationalization and the naming draft X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Wed, Apr 26, 2006 at 05:38:08PM -0400, Jeffrey Altman wrote: > (2) internationalization of GSS-API is currently not in the charter > of this working group. I am not opposed to requesting that > the group be re-chartered in order to address the problem but > I would really like to see this group make some substantial > progress on some of our existing work items before we begin > to grapple with the internationalization problem. It doesn't have to be. First, because as Ken points out, I18N/L10N support in IETF protocols is expected. But second, the crucial part of this work falls into the GSS-APIv2u1 clarifications, which are in scope. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Apr 26 18:20:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYsNJ-0005ih-SN; Wed, 26 Apr 2006 18:20:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYsNJ-0005iX-1y for kitten@ietf.org; Wed, 26 Apr 2006 18:20:45 -0400 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYsNI-0002Py-Kg for kitten@ietf.org; Wed, 26 Apr 2006 18:20:45 -0400 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id k3QMKhif017472 for ; Wed, 26 Apr 2006 15:20:44 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id k3QMIxda008487 for ; Wed, 26 Apr 2006 16:18:59 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k3QMIsYt009497; Wed, 26 Apr 2006 17:18:54 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k3QMIsQT009496; Wed, 26 Apr 2006 17:18:54 -0500 (CDT) Date: Wed, 26 Apr 2006 17:18:54 -0500 From: Nicolas Williams To: Sam Hartman Message-ID: <20060426221854.GM8152@binky.Central.Sun.COM> Mail-Followup-To: Sam Hartman , kitten@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: kitten@ietf.org Subject: Re: Charter: internationalization is out of scope X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org Simpler: I18N is out of scope, but GSS-APIv2u1 clarifications are in scope, which means that... ...we can clarify the locale/codeset issue while leaving Unicode-specific versions of GSS_Display_name(), GSS_Display_status() (which would also need localization, i.e., langtags) and GSS_Import_name() out of scope. The I18N/L10N clarification is trivial: - for name types other than GSS_C_NT_EXPORTED_NAME the input_name_string is an octet string conforming to the codeset of the current locale; - the name_string and status_string_set outputs of GSS_Display_name() and GSS_Display_status(), respectively, are octet strings conforming to the codeset of the current locale; - the status_string_set output GSS_Display_status() is to be localized to the language of the current locale. We might have to say something about locales, but not much more than this. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Apr 26 18:26:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYsST-0000I1-O0; Wed, 26 Apr 2006 18:26:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYsSS-0000Ht-Nz for kitten@ietf.org; Wed, 26 Apr 2006 18:26:04 -0400 Received: from chokecherry.srv.cs.cmu.edu ([128.2.185.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYsSR-00039v-Gk for kitten@ietf.org; Wed, 26 Apr 2006 18:26:04 -0400 Received: from sirius.fac.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.5/8.13.5) with ESMTP id k3QMPucM016287 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 26 Apr 2006 18:25:56 -0400 (EDT) Date: Wed, 26 Apr 2006 18:25:56 -0400 From: Jeffrey Hutzelman To: Jeffrey Altman , Sam Hartman , kitten@ietf.org Message-ID: <6AA3BA815D10DA3BC765BFC0@sirius.fac.cs.cmu.edu> In-Reply-To: <444FE840.8050909@columbia.edu> References: <20060426212007.GL8152@binky.Central.Sun.COM> <444FE840.8050909@columbia.edu> Originator-Info: login-token=Mulberry:014oTXEUzsTIUuz0+SFQIHgHn2DjxpuFBP+QV2GAQ=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: Subject: Re: internationalization and the naming draft X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Wednesday, April 26, 2006 05:38:08 PM -0400 Jeffrey Altman wrote: > Nicolas Williams wrote: >> On Wed, Apr 26, 2006 at 05:18:02PM -0400, Sam Hartman wrote: >>> I do think the issue is very important and will continue to >>> participate in the discussion. >> >> I agree, it's important, but orthogonal to your I-D. >> >> Nico > > Speaking as chair: > > Unless I hear a strong argument for why the naming problem space > cannot be described without including a description of the > internationalization problem and support for that argument I am > going to allow the working group last call to complete without its > inclusion. > > I will be doing so for two reasons: > > (1) there appears to be rough consensus that the problems are > linked in such a way that naming cannot be described without > a solution to the internationalization of GSS-API. I think the naming issues _can_ be described without solving i18n. In fact, I'd go so far as to suggest that they can probably even be _solved_ without it, and vice versa. The traffic I saw suggests we agree the issues are mostly orthogonal. However, I agree that we probably don't _want_ to solve one without the other, since that would result in rather funny semantics where some API elements are UTF-8 while others are 8859-1 in theory but dependent in practice on locale or some implementation-dependent equivalent. > (2) internationalization of GSS-API is currently not in the charter > of this working group. I am not opposed to requesting that > the group be re-chartered in order to address the problem but True, but this should be easy to fix. OTOH... > I would really like to see this group make some substantial > progress on some of our existing work items before we begin > to grapple with the internationalization problem. So would I. We could descend for years into the depths of the burning tar pits of hell (or whatever equivalent) attempting to solve i18n. -- Jeff _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Apr 26 18:26:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYsT3-0000eR-UA; Wed, 26 Apr 2006 18:26:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYsT2-0000eM-PQ for kitten@ietf.org; Wed, 26 Apr 2006 18:26:40 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYsT2-0003B1-JL for kitten@ietf.org; Wed, 26 Apr 2006 18:26:40 -0400 Received: from [192.168.1.13] (cpe-68-175-91-105.nyc.res.rr.com [68.175.91.105]) (user=jaltman mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.6/8.13.6) with ESMTP id k3QMQeDC013920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 26 Apr 2006 18:26:40 -0400 (EDT) Message-ID: <444FF43E.8000303@columbia.edu> Date: Wed, 26 Apr 2006 18:29:18 -0400 From: Jeffrey Altman Organization: No Longer Affiliated with Columbia University in the City of New York User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: kitten@ietf.org References: <20060426212007.GL8152@binky.Central.Sun.COM> <444FE840.8050909@columbia.edu> <20060426222033.GN8152@binky.Central.Sun.COM> In-Reply-To: <20060426222033.GN8152@binky.Central.Sun.COM> X-Enigmail-Version: 0.94.0.0 X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: Subject: Re: internationalization and the naming draft X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1208738517==" Errors-To: kitten-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============1208738517== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070104080302040809090303" This is a cryptographically signed message in MIME format. --------------ms070104080302040809090303 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Nicolas Williams wrote: > On Wed, Apr 26, 2006 at 05:38:08PM -0400, Jeffrey Altman wrote: >> (2) internationalization of GSS-API is currently not in the charter >> of this working group. I am not opposed to requesting that >> the group be re-chartered in order to address the problem but >> I would really like to see this group make some substantial >> progress on some of our existing work items before we begin >> to grapple with the internationalization problem. > > It doesn't have to be. First, because as Ken points out, I18N/L10N > support in IETF protocols is expected. But second, the crucial part of > this work falls into the GSS-APIv2u1 clarifications, which are in scope. > > Nico The areas in which GSSAPIv2 are to be clarified are specified in the charter. I18N is not one of the items listed. We need to add I18N to the charter. Jeffrey Altman --------------ms070104080302040809090303 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJPzCC AvowggJjoAMCAQICAw7NrDANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUwNTI3MTc0MjQzWhcNMDYwNTI3MTc0MjQz WjBrMQ8wDQYDVQQEEwZBbHRtYW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMT SmVmZnJleSBFcmljIEFsdG1hbjEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBjb2x1bWJpYS5l ZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+LutDu/YyHreNfoYd+ZtOjXsL h67F2cmcVuBPBz+ZGDA+WpVEHrqXaZZO8acXBR5uAVfiwA1acE/kvD/CN5kAqx1VJuQ8Pvyk iGHhUYTd27ZTliBIrptC7C/381gVwkS+a8jQFPJPO+OktZDzAYplGRY/MQCV8dIsvXUjucox 7TwTTdoLAJYRvHtfEcaCc6mO4ph6NeXQw8Grlx3IRAlTrkE5fBGyjH6R4fqnFTXRQAh1/bG+ i8hQvE6mud3mXdL2t7NP1Qxd9wW0/F/pnWY12IFP/luc3zEzIPvAe+nJluLuSEj0LZgP16mF xBj1p+u9HPWcHRVX6q7+MQ0RWOv1AgMBAAGjMTAvMB8GA1UdEQQYMBaBFGphbHRtYW5AY29s dW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAUDUuzxiq8bbI8vq2 swRK513RphZp+fepyKU5mwBI6aF4GcmqITQILtfTG2SXnjSeY99d+bjOdK1DJFvVh9aOy8mh 2NbEnqMnJIZtg5+eEU64DIV5bQdDRpi99H9vA0sRATIquut+3YHba+zArj0VkVof2VI+ToBu sHdtSrZYo0gwggL6MIICY6ADAgECAgMOzawwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA1MDUyNzE3NDI0M1oXDTA2 MDUyNzE3NDI0M1owazEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMx HDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xIzAhBgkqhkiG9w0BCQEWFGphbHRtYW5A Y29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvi7rQ7v2Mh63 jX6GHfmbTo17C4euxdnJnFbgTwc/mRgwPlqVRB66l2mWTvGnFwUebgFX4sANWnBP5Lw/wjeZ AKsdVSbkPD78pIhh4VGE3du2U5YgSK6bQuwv9/NYFcJEvmvI0BTyTzvjpLWQ8wGKZRkWPzEA lfHSLL11I7nKMe08E03aCwCWEbx7XxHGgnOpjuKYejXl0MPBq5cdyEQJU65BOXwRsox+keH6 pxU10UAIdf2xvovIULxOprnd5l3S9rezT9UMXfcFtPxf6Z1mNdiBT/5bnN8xMyD7wHvpyZbi 7khI9C2YD9ephcQY9afrvRz1nB0VV+qu/jENEVjr9QIDAQABozEwLzAfBgNVHREEGDAWgRRq YWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAFA1 Ls8YqvG2yPL6trMESudd0aYWafn3qcilOZsASOmheBnJqiE0CC7X0xtkl540nmPfXfm4znSt QyRb1YfWjsvJodjWxJ6jJySGbYOfnhFOuAyFeW0HQ0aYvfR/bwNLEQEyKrrrft2B22vswK49 FZFaH9lSPk6AbrB3bUq2WKNIMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAzswggM3AgEB MGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMOzaww CQYFKw4DAhoFAKCCAacwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMDYwNDI2MjIyOTE4WjAjBgkqhkiG9w0BCQQxFgQUmP5MbtFB+6dKRU09rvsOpf4uEEUw UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw7NrDB6BgsqhkiG9w0B CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AgMOzawwDQYJKoZIhvcNAQEBBQAEggEATjN7/DvcMLQqP8O3f12FZk+b/OmSJssiYDOC2JKs n+EwiT6NQNgTB/H9xV+aRxKcc9czWrjBTsiLMoYnwPFyTsnyv5ArYYM9ahKHGnsdTC4iOn6v Mb8hhibvZhDsY53ey8WFo5t7aw68qXNDABwTw3gklmlOtMLD7Nb8Wq1I5OzjE4pnqrwi4cVF aNoC/hhEQRU2t+/j8URyUvh4lQgjSyN3TogtrILwl87V2lYI54+q0gPI+cly3ilr5InydLRI KqR75R5naQcLsRfA30UI6kqRgXu40+nuNp8aMaS+opP4zt+QLxMmhUjtTLZlDngFZQYHgOjZ DBgCt0ta93RAbAAAAAAAAA== --------------ms070104080302040809090303-- --===============1208738517== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten --===============1208738517==-- From kitten-bounces@lists.ietf.org Wed Apr 26 18:29:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYsW7-0001Jl-8x; Wed, 26 Apr 2006 18:29:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYsW6-0001Jg-H4 for kitten@ietf.org; Wed, 26 Apr 2006 18:29:50 -0400 Received: from chokecherry.srv.cs.cmu.edu ([128.2.185.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYsW6-0003OI-9T for kitten@ietf.org; Wed, 26 Apr 2006 18:29:50 -0400 Received: from sirius.fac.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.5/8.13.5) with ESMTP id k3QMTm2H016360 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 26 Apr 2006 18:29:49 -0400 (EDT) Date: Wed, 26 Apr 2006 18:29:48 -0400 From: Jeffrey Hutzelman To: Nicolas Williams , Sam Hartman Message-ID: <74558E1240D5EB7BBF845EBA@sirius.fac.cs.cmu.edu> In-Reply-To: <20060426221854.GM8152@binky.Central.Sun.COM> References: <20060426221854.GM8152@binky.Central.Sun.COM> Originator-Info: login-token=Mulberry:017NI7tFY6sCg4HbM1H1BrI4NEct9zBrRZR2kZIlI=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: kitten@ietf.org Subject: Re: Charter: internationalization is out of scope X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Wednesday, April 26, 2006 05:18:54 PM -0500 Nicolas Williams wrote: > Simpler: > > I18N is out of scope, but GSS-APIv2u1 clarifications are in scope, which > means that... > > ...we can clarify the locale/codeset issue while leaving > Unicode-specific versions of GSS_Display_name(), GSS_Display_status() > (which would also need localization, i.e., langtags) and > GSS_Import_name() out of scope. > > The I18N/L10N clarification is trivial: > > - for name types other than GSS_C_NT_EXPORTED_NAME the > input_name_string is an octet string conforming to the codeset of the > current locale; > > - the name_string and status_string_set outputs of GSS_Display_name() > and GSS_Display_status(), respectively, are octet strings conforming > to the codeset of the current locale; > > - the status_string_set output GSS_Display_status() is to be localized > to the language of the current locale. > > We might have to say something about locales, but not much more than > this. Well, I don't think we can just say "locale", but we can put in some language about user preferences and/or operating-system settings that means locale-or-whatever-equivalent. It's not entirely clear to me that we're allowed to make this sort of change in GSSAPIv2u1 at all, since it's technically incompatible with the existing spec. But if the reality is that that's what all the implementations are actually doing, then it seems like fixing the spec to reflect reality is the right thing. -- Jeff _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Apr 26 18:36:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYsc7-0003If-V5; Wed, 26 Apr 2006 18:36:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYsc6-0003IL-Os for kitten@ietf.org; Wed, 26 Apr 2006 18:36:02 -0400 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYsc3-0003mm-4V for kitten@ietf.org; Wed, 26 Apr 2006 18:36:02 -0400 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id k3QMZwrM009095 for ; Wed, 26 Apr 2006 15:35:58 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id k3QMZvcc004212 for ; Wed, 26 Apr 2006 16:35:57 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k3QMZuMD009516; Wed, 26 Apr 2006 17:35:56 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k3QMZuNU009515; Wed, 26 Apr 2006 17:35:56 -0500 (CDT) Date: Wed, 26 Apr 2006 17:35:56 -0500 From: Nicolas Williams To: Jeffrey Hutzelman Message-ID: <20060426223556.GO8152@binky.Central.Sun.COM> Mail-Followup-To: Jeffrey Hutzelman , Sam Hartman , kitten@ietf.org References: <20060426221854.GM8152@binky.Central.Sun.COM> <74558E1240D5EB7BBF845EBA@sirius.fac.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <74558E1240D5EB7BBF845EBA@sirius.fac.cs.cmu.edu> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: kitten@ietf.org, Sam Hartman Subject: Re: Charter: internationalization is out of scope X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Wed, Apr 26, 2006 at 06:29:48PM -0400, Jeffrey Hutzelman wrote: > Well, I don't think we can just say "locale", but we can put in some > language about user preferences and/or operating-system settings that means > locale-or-whatever-equivalent. Why not? RFC3536 talks about locales... > It's not entirely clear to me that we're allowed to make this sort of > change in GSSAPIv2u1 at all, since it's technically incompatible with the > existing spec. But if the reality is that that's what all the > implementations are actually doing, then it seems like fixing the spec to > reflect reality is the right thing. No, the GSS-APIv2u1 is *broken* in this respect. Period. Noone implements GSS-API mechglue that enforces the use of Latin-1 and noone implements GSS-API applications that convert between whatever codeset is used above to/from Latin-1 in the GSS-API calls. We'd be correcting the spec, not changing it. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Apr 26 18:40:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYsgg-0005pi-M5; Wed, 26 Apr 2006 18:40:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYsge-0005jV-TV for kitten@ietf.org; Wed, 26 Apr 2006 18:40:44 -0400 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYsge-0004D4-Hg for kitten@ietf.org; Wed, 26 Apr 2006 18:40:44 -0400 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id k3QMehrM010642 for ; Wed, 26 Apr 2006 15:40:44 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id k3QMegcc006403 for ; Wed, 26 Apr 2006 16:40:43 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k3QMeglm009532; Wed, 26 Apr 2006 17:40:42 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k3QMegP2009531; Wed, 26 Apr 2006 17:40:42 -0500 (CDT) Date: Wed, 26 Apr 2006 17:40:42 -0500 From: Nicolas Williams To: Jeffrey Altman Message-ID: <20060426224042.GQ8152@binky.Central.Sun.COM> Mail-Followup-To: Jeffrey Altman , kitten@ietf.org References: <20060426212007.GL8152@binky.Central.Sun.COM> <444FE840.8050909@columbia.edu> <20060426222033.GN8152@binky.Central.Sun.COM> <444FF43E.8000303@columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <444FF43E.8000303@columbia.edu> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: kitten@ietf.org Subject: Re: internationalization and the naming draft X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Wed, Apr 26, 2006 at 06:29:18PM -0400, Jeffrey Altman wrote: > The areas in which GSSAPIv2 are to be clarified are specified in the > charter. I18N is not one of the items listed. The GSS-APIv2u1 is broken in this regard. We're wasting bandwidth. Besides, I clearly recall discussing this at Paris, where you had us go through a clarification excercise. Or is my memory failing me? Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Apr 26 18:47:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYsmu-0000x3-T6; Wed, 26 Apr 2006 18:47:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYsmu-0000wy-2j for kitten@ietf.org; Wed, 26 Apr 2006 18:47:12 -0400 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYsmt-0004XN-NF for kitten@ietf.org; Wed, 26 Apr 2006 18:47:12 -0400 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id k3QMlArM012866 for ; Wed, 26 Apr 2006 15:47:10 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id k3QMl9cc008924 for ; Wed, 26 Apr 2006 16:47:10 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k3QMl9Kb009539; Wed, 26 Apr 2006 17:47:09 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k3QMl94Q009538; Wed, 26 Apr 2006 17:47:09 -0500 (CDT) Date: Wed, 26 Apr 2006 17:47:09 -0500 From: Nicolas Williams To: Jeffrey Altman , kitten@ietf.org Message-ID: <20060426224709.GR8152@binky.Central.Sun.COM> Mail-Followup-To: Jeffrey Altman , kitten@ietf.org References: <20060426212007.GL8152@binky.Central.Sun.COM> <444FE840.8050909@columbia.edu> <20060426222033.GN8152@binky.Central.Sun.COM> <444FF43E.8000303@columbia.edu> <20060426224042.GQ8152@binky.Central.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060426224042.GQ8152@binky.Central.Sun.COM> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Subject: Re: internationalization and the naming draft X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Wed, Apr 26, 2006 at 05:40:42PM -0500, Nicolas Williams wrote: > Besides, I clearly recall discussing this at Paris, where you had us go > through a clarification excercise. Or is my memory failing me? Not Paris, Vancouver. From the proceedings: >The working group during the meeting wrote text for this document. >Sections include: > - Character-set issues > ... Who's the keeper of that text? Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Apr 26 18:48:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYsoP-0001R0-C7; Wed, 26 Apr 2006 18:48:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYsoO-0001Qv-MQ for kitten@ietf.org; Wed, 26 Apr 2006 18:48:44 -0400 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYsoN-0004hC-7f for kitten@ietf.org; Wed, 26 Apr 2006 18:48:44 -0400 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id k3QMmgrM013491 for ; Wed, 26 Apr 2006 15:48:42 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id k3QMmfcc009442 for ; Wed, 26 Apr 2006 16:48:42 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k3QMmf4u009546; Wed, 26 Apr 2006 17:48:41 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k3QMmfEj009545; Wed, 26 Apr 2006 17:48:41 -0500 (CDT) Date: Wed, 26 Apr 2006 17:48:41 -0500 From: Nicolas Williams To: Jeffrey Altman , kitten@ietf.org Message-ID: <20060426224841.GS8152@binky.Central.Sun.COM> Mail-Followup-To: Jeffrey Altman , kitten@ietf.org References: <20060426212007.GL8152@binky.Central.Sun.COM> <444FE840.8050909@columbia.edu> <20060426222033.GN8152@binky.Central.Sun.COM> <444FF43E.8000303@columbia.edu> <20060426224042.GQ8152@binky.Central.Sun.COM> <20060426224709.GR8152@binky.Central.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060426224709.GR8152@binky.Central.Sun.COM> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Subject: Re: internationalization and the naming draft X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Wed, Apr 26, 2006 at 05:47:09PM -0500, Nicolas Williams wrote: > Not Paris, Vancouver. From the proceedings: > > >The working group during the meeting wrote text for this document. > >Sections include: > > - Character-set issues > > ... > > Who's the keeper of that text? D'oh, it's in the proceedings: >Proposed Text from Nico Williams: Character Set issues. >RFC 2744 refers to Latin-1. However, the character set issues >within mechanisms expose themselves via GSS. Nico proposes >removing references to Latin-1 in the C Bindings and adding text >to the generic API specifying: > > the character set used for gss_import_name(), gss_display_name(), > gss_display_status() and any other places where one is needed will be > determined by the application's/platform's locale _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Apr 27 10:04:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ769-0008Lo-M2; Thu, 27 Apr 2006 10:04:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ768-0008Lj-FH for kitten@ietf.org; Thu, 27 Apr 2006 10:04:00 -0400 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZ767-0006qO-0a for kitten@ietf.org; Thu, 27 Apr 2006 10:04:00 -0400 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id QAA01796; Thu, 27 Apr 2006 16:03:48 +0200 (MESZ) From: Martin Rex Message-Id: <200604271403.QAA20890@uw1048.wdf.sap.corp> To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Thu, 27 Apr 2006 16:03:47 +0200 (MET DST) In-Reply-To: <20060426223556.GO8152@binky.Central.Sun.COM> from "Nicolas Williams" at Apr 26, 6 05:35:56 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: kitten@ietf.org, hartmans-ietf@mit.edu Subject: Re: Charter: internationalization is out of scope X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org Nicolas Williams wrote: > > > It's not entirely clear to me that we're allowed to make this sort of > > change in GSSAPIv2u1 at all, since it's technically incompatible with the > > existing spec. But if the reality is that that's what all the > > implementations are actually doing, then it seems like fixing the spec to > > reflect reality is the right thing. > > No, the GSS-APIv2u1 is *broken* in this respect. Period. Nope, not really. GSS-APIv2u1 high level doesn't touch the issue, because it is language dependent. JAVA natively uses Unicode, so there the issue is not visible at the language/API level, but with Kerberos and rfc-1510 interoperability, it does still exist at lower levels! The C-Bindings document defines printable strings to use iso-latin-1 single-byte codepage, NOT locale. > > Noone implements GSS-API mechglue that enforces the use of Latin-1 and > noone implements GSS-API applications that convert between whatever > codeset is used above to/from Latin-1 in the GSS-API calls. I have shipped code that relies on the strings to be iso-latin-1 (because my code sends the printable name through the network, and I did have EBCDIC and ASCII machines) and most code that I know (including MIT Kerberos) uses the just-send-8, which is DIFFERENT from using the locale -- because depending on the situation, the locale of the KDC or the locale of the client will determine the codepage of what the acceptor will get returned from gss_display_name() for the src_name of the initiator. And the locale of the server will likely be entirely ignored! -- which clearly indicates that a notion that current gssapi implementations are using the locale may often be ill-conceived. I don't know whether OpenSSL is doing any codepage conversions (based on locale). The abuse of Microsoft and Netscape by using ISO-latin-1 for subject distinguished names in X.509 certs while tagging them as T61 seems to be an indication that "locale" (and code-page-conversions) is rarely used and that "just-send-8"/"just-use-8" is the most common case. > > We'd be correcting the spec, not changing it. It would be definitely a backward incompatible change, and therefore we can NOT invalidate the use of ISO-Latin-1. The most common implementation (including MIT Kerberos) is NOT to use the locale, but instead to use "just-send-8", which is substantially different--because the use of a locale will require you to perform conversions if the user changes the locale -- which most code simply doesn't do today -- instead of continuing to "just-send-8". GSS-API normally involves two differing communicating parties (or more), and these may have different settings and desires/requirements for their locale. And what do you do with characters of a name that do not exist in the user-configured locale? Do you abort with an error (i.e. fail safe but uncomfortably for the user) or do you use a dummy character indicating a failed character conversion? The only thing that we might do about the existing spec is (a) document behaviour of existing implementations (b) recommend a particular behaviour (c) suggest how to correctly implement support for UTF-8 throughout the entire infrastructure -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Apr 27 10:16:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ7IX-0006DD-L5; Thu, 27 Apr 2006 10:16:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ7IW-0006D3-Ed for kitten@ietf.org; Thu, 27 Apr 2006 10:16:48 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZ7IT-0007XU-0d for kitten@ietf.org; Thu, 27 Apr 2006 10:16:48 -0400 Received: from centralmail2brm.Central.Sun.COM (centralmail2brm.central.sun.com [129.147.62.14]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id k3REGiaN016759 for ; Thu, 27 Apr 2006 08:16:44 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id k3REGfdc016372 for ; Thu, 27 Apr 2006 08:16:42 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k3REGdg1010154; Thu, 27 Apr 2006 09:16:39 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k3REGbEC010153; Thu, 27 Apr 2006 09:16:37 -0500 (CDT) Date: Thu, 27 Apr 2006 09:16:37 -0500 From: Nicolas Williams To: Martin Rex Message-ID: <20060427141637.GX8152@binky.Central.Sun.COM> Mail-Followup-To: Martin Rex , jhutz@cmu.edu, kitten@ietf.org, hartmans-ietf@mit.edu References: <20060426223556.GO8152@binky.Central.Sun.COM> <200604271403.QAA20890@uw1048.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200604271403.QAA20890@uw1048.wdf.sap.corp> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Cc: kitten@ietf.org, hartmans-ietf@mit.edu Subject: Re: Charter: internationalization is out of scope X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Thu, Apr 27, 2006 at 04:03:47PM +0200, Martin Rex wrote: > The C-Bindings document defines printable strings to use > iso-latin-1 single-byte codepage, NOT locale. That's *broken*. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Apr 27 10:30:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ7Va-0008Hn-Rf; Thu, 27 Apr 2006 10:30:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ7VZ-0008Hi-NF for kitten@ietf.org; Thu, 27 Apr 2006 10:30:17 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZ7VW-0008OO-Fx for kitten@ietf.org; Thu, 27 Apr 2006 10:30:17 -0400 Received: from [192.168.1.13] (cpe-68-175-91-105.nyc.res.rr.com [68.175.91.105]) (user=jaltman mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.6/8.13.6) with ESMTP id k3REUChg025272 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 27 Apr 2006 10:30:12 -0400 (EDT) Message-ID: <4450D614.9090404@columbia.edu> Date: Thu, 27 Apr 2006 10:32:52 -0400 From: Jeffrey Altman Organization: No Longer Affiliated with Columbia University in the City of New York User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Martin Rex , jhutz@cmu.edu, kitten@ietf.org, hartmans-ietf@mit.edu References: <20060426223556.GO8152@binky.Central.Sun.COM> <200604271403.QAA20890@uw1048.wdf.sap.corp> <20060427141637.GX8152@binky.Central.Sun.COM> In-Reply-To: <20060427141637.GX8152@binky.Central.Sun.COM> X-Enigmail-Version: 0.94.0.0 X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: Subject: Re: Charter: internationalization is out of scope X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1797636099==" Errors-To: kitten-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============1797636099== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080907000504020300080809" This is a cryptographically signed message in MIME format. --------------ms080907000504020300080809 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Nicolas Williams wrote: > On Thu, Apr 27, 2006 at 04:03:47PM +0200, Martin Rex wrote: >> The C-Bindings document defines printable strings to use >> iso-latin-1 single-byte codepage, NOT locale. > > That's *broken*. Nico: I have to disagree with you on this one. Its no more broken to specify the output as Latin-1 then it is to specify the output as UTF-8. The specification is stating what the output is in a consistent manner. It would be up to the calling application to convert that output to a locale dependent representation. You can argue that by specifying Latin-1 that the specification is being overly restrictive of the characters that can be represented. However, Latin-1 is broader than US-ASCII and that is all that Kerberos can utilize in a interoperable manner. Jeffrey Altman --------------ms080907000504020300080809 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJPzCC AvowggJjoAMCAQICAw7NrDANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUwNTI3MTc0MjQzWhcNMDYwNTI3MTc0MjQz WjBrMQ8wDQYDVQQEEwZBbHRtYW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMT SmVmZnJleSBFcmljIEFsdG1hbjEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBjb2x1bWJpYS5l ZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+LutDu/YyHreNfoYd+ZtOjXsL h67F2cmcVuBPBz+ZGDA+WpVEHrqXaZZO8acXBR5uAVfiwA1acE/kvD/CN5kAqx1VJuQ8Pvyk iGHhUYTd27ZTliBIrptC7C/381gVwkS+a8jQFPJPO+OktZDzAYplGRY/MQCV8dIsvXUjucox 7TwTTdoLAJYRvHtfEcaCc6mO4ph6NeXQw8Grlx3IRAlTrkE5fBGyjH6R4fqnFTXRQAh1/bG+ i8hQvE6mud3mXdL2t7NP1Qxd9wW0/F/pnWY12IFP/luc3zEzIPvAe+nJluLuSEj0LZgP16mF xBj1p+u9HPWcHRVX6q7+MQ0RWOv1AgMBAAGjMTAvMB8GA1UdEQQYMBaBFGphbHRtYW5AY29s dW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAUDUuzxiq8bbI8vq2 swRK513RphZp+fepyKU5mwBI6aF4GcmqITQILtfTG2SXnjSeY99d+bjOdK1DJFvVh9aOy8mh 2NbEnqMnJIZtg5+eEU64DIV5bQdDRpi99H9vA0sRATIquut+3YHba+zArj0VkVof2VI+ToBu sHdtSrZYo0gwggL6MIICY6ADAgECAgMOzawwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA1MDUyNzE3NDI0M1oXDTA2 MDUyNzE3NDI0M1owazEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMx HDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xIzAhBgkqhkiG9w0BCQEWFGphbHRtYW5A Y29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvi7rQ7v2Mh63 jX6GHfmbTo17C4euxdnJnFbgTwc/mRgwPlqVRB66l2mWTvGnFwUebgFX4sANWnBP5Lw/wjeZ AKsdVSbkPD78pIhh4VGE3du2U5YgSK6bQuwv9/NYFcJEvmvI0BTyTzvjpLWQ8wGKZRkWPzEA lfHSLL11I7nKMe08E03aCwCWEbx7XxHGgnOpjuKYejXl0MPBq5cdyEQJU65BOXwRsox+keH6 pxU10UAIdf2xvovIULxOprnd5l3S9rezT9UMXfcFtPxf6Z1mNdiBT/5bnN8xMyD7wHvpyZbi 7khI9C2YD9ephcQY9afrvRz1nB0VV+qu/jENEVjr9QIDAQABozEwLzAfBgNVHREEGDAWgRRq YWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAFA1 Ls8YqvG2yPL6trMESudd0aYWafn3qcilOZsASOmheBnJqiE0CC7X0xtkl540nmPfXfm4znSt QyRb1YfWjsvJodjWxJ6jJySGbYOfnhFOuAyFeW0HQ0aYvfR/bwNLEQEyKrrrft2B22vswK49 FZFaH9lSPk6AbrB3bUq2WKNIMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAzswggM3AgEB MGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMOzaww CQYFKw4DAhoFAKCCAacwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMDYwNDI3MTQzMjUyWjAjBgkqhkiG9w0BCQQxFgQUOe54t50YX1j1EfHX+9+bYqGRdRQw UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw7NrDB6BgsqhkiG9w0B CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AgMOzawwDQYJKoZIhvcNAQEBBQAEggEAhIugp/sXMKA5DbrzihGwwBMg2NftMucMoH4Rq2pW t4c8MNXuGAgmp5Jq0xVRpyy1Z/IgF7AvFoUgexgNqdrcO/pmfdHbwRJc3GmZfENl9Tnac+qy pzceg4e/1BR0M+E6ODomsCUixFSFHOOqZqnUyuZ0tWS0SAl636Nwt5ohfIE8vitgTD08Jp/+ +zGFiX0o0fglfTAntLs2jI4LGYl+5zu6pWxwJHJQ9+9ciU6ujhaAeZTQAwLw1fAcEKaOw5OP XDpqQZ/t5UETuhOMCx63qZcFrGXbj81niTiMLWxHHD4oAkH//NcL8H4OcIENuPfMElHpjDnU Nwu86elQKPYApwAAAAAAAA== --------------ms080907000504020300080809-- --===============1797636099== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten --===============1797636099==-- From kitten-bounces@lists.ietf.org Thu Apr 27 11:07:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ858-00010W-Ol; Thu, 27 Apr 2006 11:07:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ857-00010M-W5 for kitten@ietf.org; Thu, 27 Apr 2006 11:07:01 -0400 Received: from chokecherry.srv.cs.cmu.edu ([128.2.185.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZ856-0002Hz-OB for kitten@ietf.org; Thu, 27 Apr 2006 11:07:01 -0400 Received: from sirius.fac.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.5/8.13.5) with ESMTP id k3RF6thi002900 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 27 Apr 2006 11:06:56 -0400 (EDT) Date: Thu, 27 Apr 2006 11:06:55 -0400 From: Jeffrey Hutzelman To: Jeffrey Altman , Martin Rex , kitten@ietf.org, hartmans-ietf@mit.edu Message-ID: <756E88C1973BCB35D5B96A80@sirius.fac.cs.cmu.edu> In-Reply-To: <4450D614.9090404@columbia.edu> References: <20060426223556.GO8152@binky.Central.Sun.COM> <200604271403.QAA20890@uw1048.wdf.sap.corp> <20060427141637.GX8152@binky.Central.Sun.COM> <4450D614.9090404@columbia.edu> Originator-Info: login-token=Mulberry:011ScnNz+PnKshcp+4CKVXpmyZXmJcW6BCnFWcC6c=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Subject: Re: Charter: internationalization is out of scope X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Thursday, April 27, 2006 10:32:52 AM -0400 Jeffrey Altman wrote: > Nicolas Williams wrote: >> On Thu, Apr 27, 2006 at 04:03:47PM +0200, Martin Rex wrote: >>> The C-Bindings document defines printable strings to use >>> iso-latin-1 single-byte codepage, NOT locale. >> >> That's *broken*. > > Nico: > > I have to disagree with you on this one. > > Its no more broken to specify the output as Latin-1 then it > is to specify the output as UTF-8. The specification is stating > what the output is in a consistent manner. It would be up to > the calling application to convert that output to a locale > dependent representation. > > You can argue that by specifying Latin-1 that the specification is > being overly restrictive of the characters that can be represented. > However, Latin-1 is broader than US-ASCII and that is all that > Kerberos can utilize in a interoperable manner. (1) Kerberos is not the only GSS-API mechanism. (2) Nico's point is that the spec is broken because what it describes is not what any of the implementations actually _do_. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Apr 27 11:23:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ8LA-0004Ih-VW; Thu, 27 Apr 2006 11:23:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ8L9-0004Hy-46 for kitten@ietf.org; Thu, 27 Apr 2006 11:23:35 -0400 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZ8L4-0003tW-C2 for kitten@ietf.org; Thu, 27 Apr 2006 11:23:35 -0400 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id k3RFNTrM014705 for ; Thu, 27 Apr 2006 08:23:29 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id k3RFNRde015377 for ; Thu, 27 Apr 2006 09:23:28 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k3RFNRrS010211; Thu, 27 Apr 2006 10:23:27 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k3RFNR9D010210; Thu, 27 Apr 2006 10:23:27 -0500 (CDT) Date: Thu, 27 Apr 2006 10:23:27 -0500 From: Nicolas Williams To: Jeffrey Altman Message-ID: <20060427152326.GA8152@binky.Central.Sun.COM> Mail-Followup-To: Jeffrey Altman , Martin Rex , jhutz@cmu.edu, kitten@ietf.org, hartmans-ietf@mit.edu References: <20060426223556.GO8152@binky.Central.Sun.COM> <200604271403.QAA20890@uw1048.wdf.sap.corp> <20060427141637.GX8152@binky.Central.Sun.COM> <4450D614.9090404@columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4450D614.9090404@columbia.edu> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: kitten@ietf.org, hartmans-ietf@mit.edu Subject: Re: Charter: internationalization is out of scope X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Thu, Apr 27, 2006 at 10:32:52AM -0400, Jeffrey Altman wrote: > Nicolas Williams wrote: > > On Thu, Apr 27, 2006 at 04:03:47PM +0200, Martin Rex wrote: > >> The C-Bindings document defines printable strings to use > >> iso-latin-1 single-byte codepage, NOT locale. > > > > That's *broken*. > > Nico: > > I have to disagree with you on this one. Show me one of each of these: - applications that convert input_name from the current locale's codeset to Latin-1 prior to calling GSS_Import_name() for any name type other than GSS_C_NT_EXPORT_NAME... ...and which convert the output of GSS_Display_name() and GSS_Display_status() from Latin-1 to the current locale's codeset. - mechanisms that assume that the input_name in GSS_Import_name() is in Latin-1... ...and whose GSS_Display_name() and GSS_Display_status() output is in Latin-1 - mechglues that reject non-Latin-1 input_name values to GSS_Import_name() - mechglues that react in any way to mechanisms that output non-Latin-1 from GSS_Display_name() or GSS_Display_status() There are none that I can think of. Neither Heimdal, nor MIT, nor GNU, nor Solaris implementations of GSS-API framework or mechanisms, nor any of the apps that use the GSS-API that I can think of (SSHv2 [e.g., OpenSSH], SASL [e.g., Cyrus SASL], NFS w/ RPCSEC_GSS [e.g., CITI] , and so on), qualify. ALL just-use-8, which always amounts to: just-use-the-current-locale's- codeset. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Apr 27 11:25:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ8MX-0004qr-JT; Thu, 27 Apr 2006 11:25:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ8MW-0004qk-9C for kitten@ietf.org; Thu, 27 Apr 2006 11:25:00 -0400 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZ8MU-0004C6-Sk for kitten@ietf.org; Thu, 27 Apr 2006 11:25:00 -0400 Received: from centralmail2brm.Central.Sun.COM (centralmail2brm.central.sun.com [129.147.62.14]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id k3RFOw4d029081 for ; Thu, 27 Apr 2006 09:24:58 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id k3RFOude016001 for ; Thu, 27 Apr 2006 09:24:57 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k3RFOuur010219; Thu, 27 Apr 2006 10:24:56 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k3RFOuR8010218; Thu, 27 Apr 2006 10:24:56 -0500 (CDT) Date: Thu, 27 Apr 2006 10:24:56 -0500 From: Nicolas Williams To: Jeffrey Hutzelman Message-ID: <20060427152456.GB8152@binky.Central.Sun.COM> Mail-Followup-To: Jeffrey Hutzelman , Jeffrey Altman , Martin Rex , kitten@ietf.org, hartmans-ietf@mit.edu References: <20060426223556.GO8152@binky.Central.Sun.COM> <200604271403.QAA20890@uw1048.wdf.sap.corp> <20060427141637.GX8152@binky.Central.Sun.COM> <4450D614.9090404@columbia.edu> <756E88C1973BCB35D5B96A80@sirius.fac.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <756E88C1973BCB35D5B96A80@sirius.fac.cs.cmu.edu> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: kitten@ietf.org, hartmans-ietf@mit.edu Subject: Re: Charter: internationalization is out of scope X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Thu, Apr 27, 2006 at 11:06:55AM -0400, Jeffrey Hutzelman wrote: > (2) Nico's point is that the spec is broken because what it describes > is not what any of the implementations actually _do_. Exactly. The spec says one thing and noone does it that way. And everyone does it the way that I propose we change the spec. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Apr 27 11:26:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ8Ng-0006hq-Gs; Thu, 27 Apr 2006 11:26:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ8Ng-0006hl-4f for kitten@ietf.org; Thu, 27 Apr 2006 11:26:12 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZ8Nd-0004ND-TH for kitten@ietf.org; Thu, 27 Apr 2006 11:26:12 -0400 Received: from [192.168.1.13] (cpe-68-175-91-105.nyc.res.rr.com [68.175.91.105]) (user=jaltman mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.6/8.13.6) with ESMTP id k3RFQ7GJ024270 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 27 Apr 2006 11:26:08 -0400 (EDT) Message-ID: <4450E32B.9080108@columbia.edu> Date: Thu, 27 Apr 2006 11:28:43 -0400 From: Jeffrey Altman Organization: No Longer Affiliated with Columbia University in the City of New York User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Jeffrey Hutzelman References: <20060426223556.GO8152@binky.Central.Sun.COM> <200604271403.QAA20890@uw1048.wdf.sap.corp> <20060427141637.GX8152@binky.Central.Sun.COM> <4450D614.9090404@columbia.edu> <756E88C1973BCB35D5B96A80@sirius.fac.cs.cmu.edu> In-Reply-To: <756E88C1973BCB35D5B96A80@sirius.fac.cs.cmu.edu> X-Enigmail-Version: 0.94.0.0 X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: kitten@ietf.org, hartmans-ietf@mit.edu Subject: Re: Charter: internationalization is out of scope X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0033879381==" Errors-To: kitten-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============0033879381== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010501030606050601080500" This is a cryptographically signed message in MIME format. --------------ms010501030606050601080500 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Jeffrey Hutzelman wrote: > (1) Kerberos is not the only GSS-API mechanism. Obviously. However it is an example. Is RFC 4120 broken because Heimdal and MIT just-send-8 and Microsoft sends Unicode? > (2) Nico's point is that the spec is broken because what it describes > is not what any of the implementations actually _do_. The fact that the implementors that we know about do not output Latin-1 does not make the spec broken. It means that the implementors didn't read it correctly when they wrote their code OR intentionally chose to do something in violation of the spec. I suspect that just-send-8 was used primarily because in the environments in which the code was written US-ASCII was the predominant character-set and at least for the Kerberos implementors the rest of the libraries were already just-send-8 and were used in environments with default locales of either ASCII or Latin-1. Changing the spec to read "just-send-8" does not make GSSAPIv2 any more interoperable then it is today. If anything it makes it worse. Specifying new variations of the existing functions that require UTF-8 would not be more interoperable but would support a broader user base. We can't go back and require UTF-8 for GSSAPIv2. That would be an incompatible change that would not provide any additional degree of interoperability because applications using the library would not be able to identify what character-set to expect. Jeffrey Altman --------------ms010501030606050601080500 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJPzCC AvowggJjoAMCAQICAw7NrDANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUwNTI3MTc0MjQzWhcNMDYwNTI3MTc0MjQz WjBrMQ8wDQYDVQQEEwZBbHRtYW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMT SmVmZnJleSBFcmljIEFsdG1hbjEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBjb2x1bWJpYS5l ZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+LutDu/YyHreNfoYd+ZtOjXsL h67F2cmcVuBPBz+ZGDA+WpVEHrqXaZZO8acXBR5uAVfiwA1acE/kvD/CN5kAqx1VJuQ8Pvyk iGHhUYTd27ZTliBIrptC7C/381gVwkS+a8jQFPJPO+OktZDzAYplGRY/MQCV8dIsvXUjucox 7TwTTdoLAJYRvHtfEcaCc6mO4ph6NeXQw8Grlx3IRAlTrkE5fBGyjH6R4fqnFTXRQAh1/bG+ i8hQvE6mud3mXdL2t7NP1Qxd9wW0/F/pnWY12IFP/luc3zEzIPvAe+nJluLuSEj0LZgP16mF xBj1p+u9HPWcHRVX6q7+MQ0RWOv1AgMBAAGjMTAvMB8GA1UdEQQYMBaBFGphbHRtYW5AY29s dW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAUDUuzxiq8bbI8vq2 swRK513RphZp+fepyKU5mwBI6aF4GcmqITQILtfTG2SXnjSeY99d+bjOdK1DJFvVh9aOy8mh 2NbEnqMnJIZtg5+eEU64DIV5bQdDRpi99H9vA0sRATIquut+3YHba+zArj0VkVof2VI+ToBu sHdtSrZYo0gwggL6MIICY6ADAgECAgMOzawwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA1MDUyNzE3NDI0M1oXDTA2 MDUyNzE3NDI0M1owazEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMx HDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xIzAhBgkqhkiG9w0BCQEWFGphbHRtYW5A Y29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvi7rQ7v2Mh63 jX6GHfmbTo17C4euxdnJnFbgTwc/mRgwPlqVRB66l2mWTvGnFwUebgFX4sANWnBP5Lw/wjeZ AKsdVSbkPD78pIhh4VGE3du2U5YgSK6bQuwv9/NYFcJEvmvI0BTyTzvjpLWQ8wGKZRkWPzEA lfHSLL11I7nKMe08E03aCwCWEbx7XxHGgnOpjuKYejXl0MPBq5cdyEQJU65BOXwRsox+keH6 pxU10UAIdf2xvovIULxOprnd5l3S9rezT9UMXfcFtPxf6Z1mNdiBT/5bnN8xMyD7wHvpyZbi 7khI9C2YD9ephcQY9afrvRz1nB0VV+qu/jENEVjr9QIDAQABozEwLzAfBgNVHREEGDAWgRRq YWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAFA1 Ls8YqvG2yPL6trMESudd0aYWafn3qcilOZsASOmheBnJqiE0CC7X0xtkl540nmPfXfm4znSt QyRb1YfWjsvJodjWxJ6jJySGbYOfnhFOuAyFeW0HQ0aYvfR/bwNLEQEyKrrrft2B22vswK49 FZFaH9lSPk6AbrB3bUq2WKNIMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAzswggM3AgEB MGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMOzaww CQYFKw4DAhoFAKCCAacwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMDYwNDI3MTUyODQzWjAjBgkqhkiG9w0BCQQxFgQUGmfLV6VXzsalpJCaGSTjestU9pkw UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw7NrDB6BgsqhkiG9w0B CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AgMOzawwDQYJKoZIhvcNAQEBBQAEggEAB9CLa+OO7JWKh9aOnh0pXo4r412n1gvRURkrWSVY ede7WPu69lKOdQGYCtzPzVOWi7P9v08xXyasLWcp9EXXE342dG6aTHDDwXhN70+THozLAxif iVOigO1res8ERjW5Vphaw1Irz3HDDU8rrZxjCFDBqcEfknQMstWO7OBGBd9epNUqv6WFPsQr bvjC3w5iPh9DXyDODc5ukK+j8tSf9g0zfWEL//MRGuqNNc2P3GXT/su+7oS5g43qpcHDsypi UOvkWkNEFgVow9C+t0KHYkwLYa/yfLJitSXjJ6l/C0EbDKaisthlJyEti/lx02c1ZNmmJj81 oyKniHKisiiPdgAAAAAAAA== --------------ms010501030606050601080500-- --===============0033879381== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten --===============0033879381==-- From kitten-bounces@lists.ietf.org Thu Apr 27 11:27:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ8PK-0007e8-HC; Thu, 27 Apr 2006 11:27:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ8PK-0007e3-3z for kitten@ietf.org; Thu, 27 Apr 2006 11:27:54 -0400 Received: from chokecherry.srv.cs.cmu.edu ([128.2.185.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZ8PI-0004YX-Tx for kitten@ietf.org; Thu, 27 Apr 2006 11:27:54 -0400 Received: from sirius.fac.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.5/8.13.5) with ESMTP id k3RFRmSg003547 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 27 Apr 2006 11:27:48 -0400 (EDT) Date: Thu, 27 Apr 2006 11:27:48 -0400 From: Jeffrey Hutzelman To: Nicolas Williams , Jeffrey Altman Message-ID: In-Reply-To: <20060427152326.GA8152@binky.Central.Sun.COM> References: <20060426223556.GO8152@binky.Central.Sun.COM> <200604271403.QAA20890@uw1048.wdf.sap.corp> <20060427141637.GX8152@binky.Central.Sun.COM> <4450D614.9090404@columbia.edu> <20060427152326.GA8152@binky.Central.Sun.COM> Originator-Info: login-token=Mulberry:016VY0eFO+qew1oaz5HNRk54DIa6Nwiq1Wy2LdH9Y=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: kitten@ietf.org, hartmans-ietf@mit.edu Subject: Re: Charter: internationalization is out of scope X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Thursday, April 27, 2006 10:23:27 AM -0500 Nicolas Williams wrote: > - mechglues that reject non-Latin-1 input_name values to > GSS_Import_name() There can't be such a thing. All octet strings are valid latin-1. > - mechglues that react in any way to mechanisms that output non-Latin-1 > from GSS_Display_name() or GSS_Display_status() Same deal. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Apr 27 11:31:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ8Sa-00020K-HA; Thu, 27 Apr 2006 11:31:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ8SZ-00020F-1F for kitten@ietf.org; Thu, 27 Apr 2006 11:31:15 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZ8SX-0004uU-Kr for kitten@ietf.org; Thu, 27 Apr 2006 11:31:15 -0400 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id k3RFVD8x018389 for ; Thu, 27 Apr 2006 09:31:13 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id k3RFVBde020011 for ; Thu, 27 Apr 2006 09:31:12 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k3RFV8VY010226; Thu, 27 Apr 2006 10:31:08 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k3RFV8dU010225; Thu, 27 Apr 2006 10:31:08 -0500 (CDT) Date: Thu, 27 Apr 2006 10:31:07 -0500 From: Nicolas Williams To: Jeffrey Hutzelman Message-ID: <20060427153107.GC8152@binky.Central.Sun.COM> Mail-Followup-To: Jeffrey Hutzelman , Jeffrey Altman , kitten@ietf.org, hartmans-ietf@mit.edu References: <20060426223556.GO8152@binky.Central.Sun.COM> <200604271403.QAA20890@uw1048.wdf.sap.corp> <20060427141637.GX8152@binky.Central.Sun.COM> <4450D614.9090404@columbia.edu> <20060427152326.GA8152@binky.Central.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: kitten@ietf.org, hartmans-ietf@mit.edu Subject: Re: Charter: internationalization is out of scope X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Thu, Apr 27, 2006 at 11:27:48AM -0400, Jeffrey Hutzelman wrote: > On Thursday, April 27, 2006 10:23:27 AM -0500 Nicolas Williams > wrote: > > - mechglues that reject non-Latin-1 input_name values to > > GSS_Import_name() > > There can't be such a thing. All octet strings are valid latin-1. I don't have my references handy, but I thought there were some codes in the ISO8859-1 codeset that were not allocated. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Apr 27 11:32:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ8Tf-0002OE-Qq; Thu, 27 Apr 2006 11:32:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ8Tf-0002O9-JD for kitten@ietf.org; Thu, 27 Apr 2006 11:32:23 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZ8Te-00052E-7B for kitten@ietf.org; Thu, 27 Apr 2006 11:32:23 -0400 Received: from centralmail2brm.Central.Sun.COM (centralmail2brm.central.sun.com [129.147.62.14]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id k3RFWLaN001141 for ; Thu, 27 Apr 2006 09:32:21 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id k3RFWJde020719 for ; Thu, 27 Apr 2006 09:32:21 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k3RFWJIC010233; Thu, 27 Apr 2006 10:32:19 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k3RFWJsQ010232; Thu, 27 Apr 2006 10:32:19 -0500 (CDT) Date: Thu, 27 Apr 2006 10:32:19 -0500 From: Nicolas Williams To: Jeffrey Altman Message-ID: <20060427153219.GD8152@binky.Central.Sun.COM> Mail-Followup-To: Jeffrey Altman , Jeffrey Hutzelman , kitten@ietf.org, hartmans-ietf@mit.edu References: <20060426223556.GO8152@binky.Central.Sun.COM> <200604271403.QAA20890@uw1048.wdf.sap.corp> <20060427141637.GX8152@binky.Central.Sun.COM> <4450D614.9090404@columbia.edu> <756E88C1973BCB35D5B96A80@sirius.fac.cs.cmu.edu> <4450E32B.9080108@columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4450E32B.9080108@columbia.edu> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: kitten@ietf.org, hartmans-ietf@mit.edu Subject: Re: Charter: internationalization is out of scope X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Thu, Apr 27, 2006 at 11:28:43AM -0400, Jeffrey Altman wrote: > Jeffrey Hutzelman wrote: > > (2) Nico's point is that the spec is broken because what it describes > > is not what any of the implementations actually _do_. > > The fact that the implementors that we know about do not output > Latin-1 does not make the spec broken. It means that the implementors > didn't read it correctly when they wrote their code OR intentionally > chose to do something in violation of the spec. Noone in their right mind will implement what the spec says in this case. I dare MIT to do it ;) -- I know MIT won't, because MIT isn't insane. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Apr 27 11:35:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ8Wn-0003uZ-Ix; Thu, 27 Apr 2006 11:35:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ8Wm-0003rG-15 for kitten@ietf.org; Thu, 27 Apr 2006 11:35:36 -0400 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZ8Wl-0005KH-LS for kitten@ietf.org; Thu, 27 Apr 2006 11:35:36 -0400 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id k3RFZYrM019410 for ; Thu, 27 Apr 2006 08:35:34 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id k3RFZXde022101 for ; Thu, 27 Apr 2006 09:35:34 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k3RFZWha010240; Thu, 27 Apr 2006 10:35:32 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k3RFZWFP010239; Thu, 27 Apr 2006 10:35:32 -0500 (CDT) Date: Thu, 27 Apr 2006 10:35:32 -0500 From: Nicolas Williams To: Jeffrey Altman , Martin Rex , jhutz@cmu.edu, kitten@ietf.org, hartmans-ietf@mit.edu Message-ID: <20060427153532.GE8152@binky.Central.Sun.COM> Mail-Followup-To: Jeffrey Altman , Martin Rex , jhutz@cmu.edu, kitten@ietf.org, hartmans-ietf@mit.edu References: <20060426223556.GO8152@binky.Central.Sun.COM> <200604271403.QAA20890@uw1048.wdf.sap.corp> <20060427141637.GX8152@binky.Central.Sun.COM> <4450D614.9090404@columbia.edu> <20060427152326.GA8152@binky.Central.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060427152326.GA8152@binky.Central.Sun.COM> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Subject: Re: Charter: internationalization is out of scope X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Thu, Apr 27, 2006 at 10:23:27AM -0500, Nicolas Williams wrote: > Show me one of each of these: Or at least one of those things where you think the implementors could be convinced to make them comply with this Latin-1 requirement. There are none that I can think of, either way. Martin's mechanism and application implementations might, for all I know comply, but it seems unlikely to me. Martin? Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Apr 27 11:43:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ8ej-0006eV-3g; Thu, 27 Apr 2006 11:43:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ8ei-0006eQ-0t for kitten@ietf.org; Thu, 27 Apr 2006 11:43:48 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZ8eg-0006AU-QU for kitten@ietf.org; Thu, 27 Apr 2006 11:43:48 -0400 Received: from [192.168.1.13] (cpe-68-175-91-105.nyc.res.rr.com [68.175.91.105]) (user=jaltman mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.6/8.13.6) with ESMTP id k3RFhiRZ014668 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 27 Apr 2006 11:43:45 -0400 (EDT) Message-ID: <4450E74B.7020800@columbia.edu> Date: Thu, 27 Apr 2006 11:46:19 -0400 From: Jeffrey Altman Organization: No Longer Affiliated with Columbia University in the City of New York User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Jeffrey Hutzelman , Jeffrey Altman , kitten@ietf.org, hartmans-ietf@mit.edu References: <20060426223556.GO8152@binky.Central.Sun.COM> <200604271403.QAA20890@uw1048.wdf.sap.corp> <20060427141637.GX8152@binky.Central.Sun.COM> <4450D614.9090404@columbia.edu> <20060427152326.GA8152@binky.Central.Sun.COM> <20060427153107.GC8152@binky.Central.Sun.COM> In-Reply-To: <20060427153107.GC8152@binky.Central.Sun.COM> X-Enigmail-Version: 0.94.0.0 X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: Subject: Re: Charter: internationalization is out of scope X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0295372805==" Errors-To: kitten-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============0295372805== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020604010001050901030100" This is a cryptographically signed message in MIME format. --------------ms020604010001050901030100 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Nicolas Williams wrote: > On Thu, Apr 27, 2006 at 11:27:48AM -0400, Jeffrey Hutzelman wrote: >> On Thursday, April 27, 2006 10:23:27 AM -0500 Nicolas Williams >> wrote: >>> - mechglues that reject non-Latin-1 input_name values to >>> GSS_Import_name() >> There can't be such a thing. All octet strings are valid latin-1. > > I don't have my references handy, but I thought there were some codes in > the ISO8859-1 codeset that were not allocated. ISO-8859 specifies the printable characters outside the byte values reserved for the C0 and C1 controls. All octet strings are a valid combination of Latin-1 plus a C0 and C1 control set. The IBM/Microsoft code pages as opposed to ISO 8859 character-sets do not designate a C1 range. Therefore, octet strings that are value code pages may collide with the C1 control range. --------------ms020604010001050901030100 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJPzCC AvowggJjoAMCAQICAw7NrDANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUwNTI3MTc0MjQzWhcNMDYwNTI3MTc0MjQz WjBrMQ8wDQYDVQQEEwZBbHRtYW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMT SmVmZnJleSBFcmljIEFsdG1hbjEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBjb2x1bWJpYS5l ZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+LutDu/YyHreNfoYd+ZtOjXsL h67F2cmcVuBPBz+ZGDA+WpVEHrqXaZZO8acXBR5uAVfiwA1acE/kvD/CN5kAqx1VJuQ8Pvyk iGHhUYTd27ZTliBIrptC7C/381gVwkS+a8jQFPJPO+OktZDzAYplGRY/MQCV8dIsvXUjucox 7TwTTdoLAJYRvHtfEcaCc6mO4ph6NeXQw8Grlx3IRAlTrkE5fBGyjH6R4fqnFTXRQAh1/bG+ i8hQvE6mud3mXdL2t7NP1Qxd9wW0/F/pnWY12IFP/luc3zEzIPvAe+nJluLuSEj0LZgP16mF xBj1p+u9HPWcHRVX6q7+MQ0RWOv1AgMBAAGjMTAvMB8GA1UdEQQYMBaBFGphbHRtYW5AY29s dW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAUDUuzxiq8bbI8vq2 swRK513RphZp+fepyKU5mwBI6aF4GcmqITQILtfTG2SXnjSeY99d+bjOdK1DJFvVh9aOy8mh 2NbEnqMnJIZtg5+eEU64DIV5bQdDRpi99H9vA0sRATIquut+3YHba+zArj0VkVof2VI+ToBu sHdtSrZYo0gwggL6MIICY6ADAgECAgMOzawwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA1MDUyNzE3NDI0M1oXDTA2 MDUyNzE3NDI0M1owazEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMx HDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xIzAhBgkqhkiG9w0BCQEWFGphbHRtYW5A Y29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvi7rQ7v2Mh63 jX6GHfmbTo17C4euxdnJnFbgTwc/mRgwPlqVRB66l2mWTvGnFwUebgFX4sANWnBP5Lw/wjeZ AKsdVSbkPD78pIhh4VGE3du2U5YgSK6bQuwv9/NYFcJEvmvI0BTyTzvjpLWQ8wGKZRkWPzEA lfHSLL11I7nKMe08E03aCwCWEbx7XxHGgnOpjuKYejXl0MPBq5cdyEQJU65BOXwRsox+keH6 pxU10UAIdf2xvovIULxOprnd5l3S9rezT9UMXfcFtPxf6Z1mNdiBT/5bnN8xMyD7wHvpyZbi 7khI9C2YD9ephcQY9afrvRz1nB0VV+qu/jENEVjr9QIDAQABozEwLzAfBgNVHREEGDAWgRRq YWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAFA1 Ls8YqvG2yPL6trMESudd0aYWafn3qcilOZsASOmheBnJqiE0CC7X0xtkl540nmPfXfm4znSt QyRb1YfWjsvJodjWxJ6jJySGbYOfnhFOuAyFeW0HQ0aYvfR/bwNLEQEyKrrrft2B22vswK49 FZFaH9lSPk6AbrB3bUq2WKNIMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAzswggM3AgEB MGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMOzaww CQYFKw4DAhoFAKCCAacwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMDYwNDI3MTU0NjE5WjAjBgkqhkiG9w0BCQQxFgQUtMos+azODVytL7f4roHI59Vb0LQw UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw7NrDB6BgsqhkiG9w0B CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AgMOzawwDQYJKoZIhvcNAQEBBQAEggEAp9+1TqXGW3A8C7ziGhh0/2d5fZrhL8dpOFHLog6Q KHAmDEKS+WbydcCWJcMcs47q9ldLpsX1IoZsgLyTcyDWqzX16kwUorZPrQ5lB5dzOdo1BKe0 VXlLhsjRtRGvp4nAQzQ2U4ifSlbv9nDJmOgMicY0O1p+5XF8jssgvLgVt/2D/lUi2qzovL5m g9lCT5BS5NRbTcmnMFS1QtPIoWqXV+9h8sl51MM020bMIw202fz5oM2v2KIx4oHYrQdQBgb0 FKrmmEFpNG1bqCuq+j7O4VvfU55rqSXp9aD8n0lJG7DKOu2c4ou7f2J/GXm0IouzmD5Eb83z HnTxaBNUqJkwegAAAAAAAA== --------------ms020604010001050901030100-- --===============0295372805== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten --===============0295372805==-- From kitten-bounces@lists.ietf.org Thu Apr 27 11:44:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ8fM-0006zN-Au; Thu, 27 Apr 2006 11:44:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ8fL-0006wG-47 for kitten@ietf.org; Thu, 27 Apr 2006 11:44:27 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZ8fK-0006DJ-TE for kitten@ietf.org; Thu, 27 Apr 2006 11:44:27 -0400 Received: from [192.168.1.13] (cpe-68-175-91-105.nyc.res.rr.com [68.175.91.105]) (user=jaltman mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.6/8.13.6) with ESMTP id k3RFiPu4029178 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 27 Apr 2006 11:44:25 -0400 (EDT) Message-ID: <4450E773.7050900@columbia.edu> Date: Thu, 27 Apr 2006 11:46:59 -0400 From: Jeffrey Altman Organization: No Longer Affiliated with Columbia University in the City of New York User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Jeffrey Altman , Martin Rex , jhutz@cmu.edu, kitten@ietf.org, hartmans-ietf@mit.edu References: <20060426223556.GO8152@binky.Central.Sun.COM> <200604271403.QAA20890@uw1048.wdf.sap.corp> <20060427141637.GX8152@binky.Central.Sun.COM> <4450D614.9090404@columbia.edu> <20060427152326.GA8152@binky.Central.Sun.COM> In-Reply-To: <20060427152326.GA8152@binky.Central.Sun.COM> X-Enigmail-Version: 0.94.0.0 X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: Subject: Re: Charter: internationalization is out of scope X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0469526896==" Errors-To: kitten-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============0469526896== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030708030408080007020708" This is a cryptographically signed message in MIME format. --------------ms030708030408080007020708 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Nicolas Williams wrote: > On Thu, Apr 27, 2006 at 10:32:52AM -0400, Jeffrey Altman wrote: > Neither Heimdal, nor MIT, nor GNU, nor Solaris implementations of > GSS-API framework or mechanisms, nor any of the apps that use the > GSS-API that I can think of (SSHv2 [e.g., OpenSSH], SASL [e.g., Cyrus > SASL], NFS w/ RPCSEC_GSS [e.g., CITI] , and so on), qualify. > > ALL just-use-8, which always amounts to: just-use-the-current-locale's- > codeset. > > Nico What you are proposing is a protocol that only works when the peers are either lucky enough to use the same character-set by chance or have negotiated the character-set out of band. There is a reason we didn't change 4120 to say just-send-8. Its because we care about interoperability in our specifications. If two people independently follow the spec and produce an implementation, they should be able to communicate with one another. Therefore, 4120 clarifies that the allowable character-set is US-ASCII only. It notes that there is not a single implementation that we are aware of today that enforces this restriction and that most just-send-8. As such applications that use Kerberos use characters outside of US-ASCII at their own peril. The only clarification that makes sense to say for GSSAPIv2 is a note indication that many if not all of the known implementations just-send-8 in violation of the Latin-1 requirement. As such it is possible that names received may not in fact be Latin-1. As Martin pointed out, the Java Bindings using UTF8. That means that we already have a character-set collision problem if one peer is Java and the other is C. Changing the C binding to state "just-send-8" does not make the problem any better. Jeffrey Altman --------------ms030708030408080007020708 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJPzCC AvowggJjoAMCAQICAw7NrDANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUwNTI3MTc0MjQzWhcNMDYwNTI3MTc0MjQz WjBrMQ8wDQYDVQQEEwZBbHRtYW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMT SmVmZnJleSBFcmljIEFsdG1hbjEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBjb2x1bWJpYS5l ZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+LutDu/YyHreNfoYd+ZtOjXsL h67F2cmcVuBPBz+ZGDA+WpVEHrqXaZZO8acXBR5uAVfiwA1acE/kvD/CN5kAqx1VJuQ8Pvyk iGHhUYTd27ZTliBIrptC7C/381gVwkS+a8jQFPJPO+OktZDzAYplGRY/MQCV8dIsvXUjucox 7TwTTdoLAJYRvHtfEcaCc6mO4ph6NeXQw8Grlx3IRAlTrkE5fBGyjH6R4fqnFTXRQAh1/bG+ i8hQvE6mud3mXdL2t7NP1Qxd9wW0/F/pnWY12IFP/luc3zEzIPvAe+nJluLuSEj0LZgP16mF xBj1p+u9HPWcHRVX6q7+MQ0RWOv1AgMBAAGjMTAvMB8GA1UdEQQYMBaBFGphbHRtYW5AY29s dW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAUDUuzxiq8bbI8vq2 swRK513RphZp+fepyKU5mwBI6aF4GcmqITQILtfTG2SXnjSeY99d+bjOdK1DJFvVh9aOy8mh 2NbEnqMnJIZtg5+eEU64DIV5bQdDRpi99H9vA0sRATIquut+3YHba+zArj0VkVof2VI+ToBu sHdtSrZYo0gwggL6MIICY6ADAgECAgMOzawwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA1MDUyNzE3NDI0M1oXDTA2 MDUyNzE3NDI0M1owazEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMx HDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xIzAhBgkqhkiG9w0BCQEWFGphbHRtYW5A Y29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvi7rQ7v2Mh63 jX6GHfmbTo17C4euxdnJnFbgTwc/mRgwPlqVRB66l2mWTvGnFwUebgFX4sANWnBP5Lw/wjeZ AKsdVSbkPD78pIhh4VGE3du2U5YgSK6bQuwv9/NYFcJEvmvI0BTyTzvjpLWQ8wGKZRkWPzEA lfHSLL11I7nKMe08E03aCwCWEbx7XxHGgnOpjuKYejXl0MPBq5cdyEQJU65BOXwRsox+keH6 pxU10UAIdf2xvovIULxOprnd5l3S9rezT9UMXfcFtPxf6Z1mNdiBT/5bnN8xMyD7wHvpyZbi 7khI9C2YD9ephcQY9afrvRz1nB0VV+qu/jENEVjr9QIDAQABozEwLzAfBgNVHREEGDAWgRRq YWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAFA1 Ls8YqvG2yPL6trMESudd0aYWafn3qcilOZsASOmheBnJqiE0CC7X0xtkl540nmPfXfm4znSt QyRb1YfWjsvJodjWxJ6jJySGbYOfnhFOuAyFeW0HQ0aYvfR/bwNLEQEyKrrrft2B22vswK49 FZFaH9lSPk6AbrB3bUq2WKNIMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAzswggM3AgEB MGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMOzaww CQYFKw4DAhoFAKCCAacwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMDYwNDI3MTU0NjU5WjAjBgkqhkiG9w0BCQQxFgQUhouXn0bcmlcLwZIDRKoC75y++ykw UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw7NrDB6BgsqhkiG9w0B CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AgMOzawwDQYJKoZIhvcNAQEBBQAEggEAArjKAu2daXfI0NMK/sMYB4WLz7wAOAETC73mqc6S Q47Nx51TGMPXVAeBLt3dduaqwzTw4j4JnUlhZt1fTMRzyesC7MfjGs8xAzE3GR+ckxlRAaIt YpWGRM1JFsdCL+PL+tuslWEijd1kbWnkLTlhxOCU6Ms0B1zkaZb9eJc3rQ10L/eXGsU494Se Vwix4XPUshMvZ4E/acnI4LLPV/kFpWBqeADjqgWAbwm6h626cLeyzV/+OzIZ4aQ45XXM4Jb5 6ZRfK+JZtK1AGoIwTaIbj8ekBChd0Ql0Ib5jrOzmV0dbeWVNH745kNwYGclu5Msfa/XNvsh8 YqXYCNJxT3YElgAAAAAAAA== --------------ms030708030408080007020708-- --===============0469526896== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten --===============0469526896==-- From kitten-bounces@lists.ietf.org Thu Apr 27 11:52:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ8nQ-0008MM-6g; Thu, 27 Apr 2006 11:52:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ8nP-0008ME-Px for kitten@ietf.org; Thu, 27 Apr 2006 11:52:47 -0400 Received: from chokecherry.srv.cs.cmu.edu ([128.2.185.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZ8nP-0006nk-HJ for kitten@ietf.org; Thu, 27 Apr 2006 11:52:47 -0400 Received: from sirius.fac.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.5/8.13.5) with ESMTP id k3RFqgmx004360 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 27 Apr 2006 11:52:42 -0400 (EDT) Date: Thu, 27 Apr 2006 11:52:42 -0400 From: Jeffrey Hutzelman To: Jeffrey Altman , Martin Rex , kitten@ietf.org, hartmans-ietf@mit.edu Message-ID: In-Reply-To: <4450E773.7050900@columbia.edu> References: <20060426223556.GO8152@binky.Central.Sun.COM> <200604271403.QAA20890@uw1048.wdf.sap.corp> <20060427141637.GX8152@binky.Central.Sun.COM> <4450D614.9090404@columbia.edu> <20060427152326.GA8152@binky.Central.Sun.COM> <4450E773.7050900@columbia.edu> Originator-Info: login-token=Mulberry:01Uz3Odr2lQ+qfiEb3hrv+5eqvBaHacUfAsvzbib0=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Subject: Re: Charter: internationalization is out of scope X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Thursday, April 27, 2006 11:46:59 AM -0400 Jeffrey Altman wrote: > Nicolas Williams wrote: >> On Thu, Apr 27, 2006 at 10:32:52AM -0400, Jeffrey Altman wrote: > >> Neither Heimdal, nor MIT, nor GNU, nor Solaris implementations of >> GSS-API framework or mechanisms, nor any of the apps that use the >> GSS-API that I can think of (SSHv2 [e.g., OpenSSH], SASL [e.g., Cyrus >> SASL], NFS w/ RPCSEC_GSS [e.g., CITI] , and so on), qualify. >> >> ALL just-use-8, which always amounts to: just-use-the-current-locale's- >> codeset. >> >> Nico > > What you are proposing is a protocol that only works when the > peers are either lucky enough to use the same character-set by > chance or have negotiated the character-set out of band. Not at all, because we're not talking about a protocol or what happens on the wire. We're talking about an API, and the caller and callee are assumed to have the same locale by virtue of being, at least conceptually, in the same process. We're not talking about "just-send-8"; what you _send_ is up to the mechanism. We're talking about "just-use-8", in an API. -- Jeff _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Apr 27 11:59:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ8tz-0000g1-PZ; Thu, 27 Apr 2006 11:59:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ8tz-0000fu-7B for kitten@ietf.org; Thu, 27 Apr 2006 11:59:35 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZ8tx-0007PO-Lq for kitten@ietf.org; Thu, 27 Apr 2006 11:59:35 -0400 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id k3RFxX8x004377 for ; Thu, 27 Apr 2006 09:59:33 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id k3RFxVce026391 for ; Thu, 27 Apr 2006 09:59:32 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k3RFxVni010253; Thu, 27 Apr 2006 10:59:31 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k3RFxV8m010252; Thu, 27 Apr 2006 10:59:31 -0500 (CDT) Date: Thu, 27 Apr 2006 10:59:31 -0500 From: Nicolas Williams To: Jeffrey Altman Message-ID: <20060427155930.GF8152@binky.Central.Sun.COM> Mail-Followup-To: Jeffrey Altman , Martin Rex , jhutz@cmu.edu, kitten@ietf.org, hartmans-ietf@mit.edu References: <20060426223556.GO8152@binky.Central.Sun.COM> <200604271403.QAA20890@uw1048.wdf.sap.corp> <20060427141637.GX8152@binky.Central.Sun.COM> <4450D614.9090404@columbia.edu> <20060427152326.GA8152@binky.Central.Sun.COM> <4450E773.7050900@columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4450E773.7050900@columbia.edu> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: kitten@ietf.org, hartmans-ietf@mit.edu Subject: Re: Charter: internationalization is out of scope X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Thu, Apr 27, 2006 at 11:46:59AM -0400, Jeffrey Altman wrote: > Nicolas Williams wrote: > > On Thu, Apr 27, 2006 at 10:32:52AM -0400, Jeffrey Altman wrote: > > > Neither Heimdal, nor MIT, nor GNU, nor Solaris implementations of > > GSS-API framework or mechanisms, nor any of the apps that use the > > GSS-API that I can think of (SSHv2 [e.g., OpenSSH], SASL [e.g., Cyrus > > SASL], NFS w/ RPCSEC_GSS [e.g., CITI] , and so on), qualify. > > > > ALL just-use-8, which always amounts to: just-use-the-current-locale's- > > codeset. > > > > Nico > > What you are proposing is a protocol that only works when the ^^^^^^^^ NO. API. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Apr 27 12:25:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ9IX-0007nv-Dd; Thu, 27 Apr 2006 12:24:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ9IW-0007nq-Qm for kitten@ietf.org; Thu, 27 Apr 2006 12:24:56 -0400 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZ9IV-0000qA-De for kitten@ietf.org; Thu, 27 Apr 2006 12:24:56 -0400 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id SAA14977; Thu, 27 Apr 2006 18:24:37 +0200 (MESZ) From: Martin Rex Message-Id: <200604271620.SAA22758@uw1048.wdf.sap.corp> To: jaltman@columbia.edu (Jeffrey Altman) Date: Thu, 27 Apr 2006 18:20:50 +0200 (MET DST) In-Reply-To: <4450E773.7050900@columbia.edu> from "Jeffrey Altman" at Apr 27, 6 11:46:59 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: kitten@ietf.org, hartmans-ietf@mit.edu Subject: Re: Charter: internationalization is out of scope X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org Jeffrey Altman wrote: > > Nicolas Williams wrote: > > On Thu, Apr 27, 2006 at 10:32:52AM -0400, Jeffrey Altman wrote: > > > Neither Heimdal, nor MIT, nor GNU, nor Solaris implementations of > > GSS-API framework or mechanisms, nor any of the apps that use the > > GSS-API that I can think of (SSHv2 [e.g., OpenSSH], SASL [e.g., Cyrus > > SASL], NFS w/ RPCSEC_GSS [e.g., CITI] , and so on), qualify. > > > > ALL just-use-8, which always amounts to: just-use-the-current-locale's- > > codeset. I disagree, Nico. If I install a current Linux distribution and configure the locale for DE_de, then I get to see manpages and output of certain commands (e.g. man pages) in german. Code that detects the current locale and *CONVERTS* persistent or remotely-received accordingly is locale-aware. Kerberos, OpenSSL and a lot of other code completely ignores the configured locale and does not perform any codepage conversions, mostly because the printable data to which a conversion would have to be applied is neither tagged nor sufficiently standardized so that the code would have a chance to know where from/to a convert to. In absence of codepage conversions in the code, one should be very careful to describe behaviour as "using the current locale", because it is plain wrong, and you may realize that as soon as you *change* the locale, because some of the results will not follow and you may loose interoperability or cause security problems. Documenting it as "just-use-8"/"just-send-8" means that if the subset of characters that is used by all participants happens to use the same codepoints, then you will get interoperability independent of individual locales. If all participants happen to use the same codepage/locale, then you appear to have full interoperability on all of the codepoints/characters -- but as soon as someone wants to use a different codepage (including the use of any variant of Unicode, UTF8, UCS2, UCS4,...), then you loose if the shared/transfered printable information is neither tagged (meta-information) nor standardized to have a particular "transfer-encoding". > > The only clarification that makes sense to say for GSSAPIv2 is > a note indication that many if not all of the known implementations > just-send-8 in violation of the Latin-1 requirement. As such it > is possible that names received may not in fact be Latin-1. I fully agree. > > As Martin pointed out, the Java Bindings using UTF8. That means > that we already have a character-set collision problem if one peer > is Java and the other is C. Changing the C binding to state > "just-send-8" does not make the problem any better. Are you sure about UTF8 -- I thought that Java uses "wide characters" (UCS2? USC4?), which means that a JAVA-based gssapi for Kerberos will have to, at some point, convert from wide characters to a single byte code page as the "transfer encoding" of principal names in the Kerberos protocol -- and in case that UTF8 isn't available, you will have to decide for a particular single-byte codepage. Choosing the current single-byte locale as the transfer encoding may be easy, but it may certainly interoperability problems even with other Java peers (or the KDC) if they happen to use a different locale when the involved principal names are not from 7-bit ASCII... -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Apr 27 12:32:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ9PJ-0002jZ-Bg; Thu, 27 Apr 2006 12:31:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ9PI-0002jU-3H for kitten@ietf.org; Thu, 27 Apr 2006 12:31:56 -0400 Received: from nwkea-mail-5.sun.com ([192.18.42.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZ9PG-00018y-Il for kitten@ietf.org; Thu, 27 Apr 2006 12:31:56 -0400 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-5.sun.com (8.12.10/8.12.9) with ESMTP id k3RGVraN000823 for ; Thu, 27 Apr 2006 09:31:53 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id k3RGVqcc015663 for ; Thu, 27 Apr 2006 10:31:53 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k3RGVqtU010284; Thu, 27 Apr 2006 11:31:52 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k3RGVqCt010283; Thu, 27 Apr 2006 11:31:52 -0500 (CDT) Date: Thu, 27 Apr 2006 11:31:52 -0500 From: Nicolas Williams To: Martin Rex Message-ID: <20060427163151.GG8152@binky.Central.Sun.COM> Mail-Followup-To: Martin Rex , Jeffrey Altman , kitten@ietf.org, hartmans-ietf@mit.edu References: <4450E773.7050900@columbia.edu> <200604271620.SAA22758@uw1048.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200604271620.SAA22758@uw1048.wdf.sap.corp> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: kitten@ietf.org, hartmans-ietf@mit.edu Subject: Re: Charter: internationalization is out of scope X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Thu, Apr 27, 2006 at 06:20:50PM +0200, Martin Rex wrote: > Jeffrey Altman wrote: > > > > Nicolas Williams wrote: > > > On Thu, Apr 27, 2006 at 10:32:52AM -0400, Jeffrey Altman wrote: > > > > > Neither Heimdal, nor MIT, nor GNU, nor Solaris implementations of > > > GSS-API framework or mechanisms, nor any of the apps that use the > > > GSS-API that I can think of (SSHv2 [e.g., OpenSSH], SASL [e.g., Cyrus > > > SASL], NFS w/ RPCSEC_GSS [e.g., CITI] , and so on), qualify. > > > > > > ALL just-use-8, which always amounts to: just-use-the-current-locale's- > > > codeset. > > I disagree, Nico. > > If I install a current Linux distribution and configure the locale > for DE_de, then I get to see manpages and output of certain commands > (e.g. man pages) in german. Because the man command knows how to find them -- it had to be locale aware. > Code that detects the current locale and *CONVERTS* persistent or > remotely-received accordingly is locale-aware. Yes. GSS-API *applications* *don't* have to be. GSS-API *mechanisms* *do* have to be. But the spec (RFC2744) gets it backwards. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Apr 27 13:02:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ9tG-0006or-U1; Thu, 27 Apr 2006 13:02:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ9tG-0006om-7B for kitten@ietf.org; Thu, 27 Apr 2006 13:02:54 -0400 Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZ9tE-0002Ea-Pr for kitten@ietf.org; Thu, 27 Apr 2006 13:02:54 -0400 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id TAA23111; Thu, 27 Apr 2006 19:02:35 +0200 (MESZ) From: Martin Rex Message-Id: <200604271659.SAA23324@uw1048.wdf.sap.corp> To: jhutz@cmu.edu (Jeffrey Hutzelman) Date: Thu, 27 Apr 2006 18:59:42 +0200 (MET DST) In-Reply-To: from "Jeffrey Hutzelman" at Apr 27, 6 11:52:42 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: kitten@ietf.org, hartmans-ietf@mit.edu Subject: Re: Charter: internationalization is out of scope X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org Jeffrey Hutzelman wrote: > > Not at all, because we're not talking about a protocol or what happens on > the wire. We're talking about an API, and the caller and callee are > assumed to have the same locale by virtue of being, at least conceptually, > in the same process. > > > We're not talking about "just-send-8"; what you _send_ is up to the > mechanism. We're talking about "just-use-8", in an API. The fact that the src_name which pops out of gss_accept_sec_context() has normally not been supplied as a printable to the local GSS-API is a vital part of the service supplied by this API. The printable representation created for this src_name via gss_display_name() has been created by either by the initiator or a third party (may be a KDC, may be a CA issuing an X.509 cert) with some single-byte codepage that may differ from the locale/codepage of the server/acceptor. "Legacy" Kerberos installations (MIT,Heimdal) which have been using non-ASCII characters in usernames (and ISO-Latin-1 locales througout) may easily return invalid UTF-8 encodings when you switch the locale to UTF-8, because they are locale-ignorant and some sequences of 8-bit ISO-Latin-1 are invalid UTF-8 encodings. There is another I18N issue: the "hostbased service names" after the invention of Punycode. Currently, this means that the application has to puny-encode international host&domainnames before passing it to gss_import_name(). However this requires the application to parse and process names which historically may have been opaque to the application. Is there any document/proposal how to map between international host&domainnames to Kerberos (hostbased) service principals? Microsoft has been using UTF8 for their principal names, so they might be mislead to retain UTF8 hostnames within Kerberos principal names -- however this creates a problem as to define who and where (API-level: kerb-mech or app) will have to convert international host&domainnames into punycode and which one is the "canonical" encoding at the protocol level. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Apr 27 13:21:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZABY-0003I1-Fx; Thu, 27 Apr 2006 13:21:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZABY-0003Hw-8f for kitten@ietf.org; Thu, 27 Apr 2006 13:21:48 -0400 Received: from carter-zimmerman.dyn.mit.edu ([18.188.3.148] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZABV-0003EY-1x for kitten@ietf.org; Thu, 27 Apr 2006 13:21:48 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 8F4D8E0053; Thu, 27 Apr 2006 13:21:37 -0400 (EDT) To: martin.rex@sap.com References: <200604271659.SAA23324@uw1048.wdf.sap.corp> From: Sam Hartman Date: Thu, 27 Apr 2006 13:21:37 -0400 In-Reply-To: <200604271659.SAA23324@uw1048.wdf.sap.corp> (Martin Rex's message of "Thu, 27 Apr 2006 18:59:42 +0200 (MET DST)") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: kitten@ietf.org Subject: Re: Charter: internationalization is out of scope X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org >>>>> "Martin" == Martin Rex writes: Martin> There is another I18N issue: the "hostbased service names" Martin> after the invention of Punycode. Currently, this means Martin> that the application has to puny-encode international Martin> host&domainnames before passing it to gss_import_name(). Martin> However this requires the application to parse and process Martin> names which historically may have been opaque to the Martin> application. Martin> Is there any document/proposal how to map between Martin> international host&domainnames to Kerberos (hostbased) Martin> service principals? Microsoft has been using UTF8 for Martin> their principal names, so they might be mislead to retain Martin> UTF8 hostnames within Kerberos principal names -- however Martin> this creates a problem as to define who and where Martin> (API-level: kerb-mech or app) will have to convert Martin> international host&domainnames into punycode and which one Martin> is the "canonical" encoding at the protocol level. There has been a lot of discussion of this issue. I don't remember what the final resolution was; we went back and forth a lot. --Sam _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Apr 27 13:52:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZAfY-0005vW-N6; Thu, 27 Apr 2006 13:52:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZAfY-0005vR-Cl for kitten@ietf.org; Thu, 27 Apr 2006 13:52:48 -0400 Received: from carter-zimmerman.dyn.mit.edu ([18.188.3.148] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZAfX-0005MG-78 for kitten@ietf.org; Thu, 27 Apr 2006 13:52:48 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 138EEE0053; Thu, 27 Apr 2006 13:52:40 -0400 (EDT) To: Ken Raeburn References: From: Sam Hartman Date: Thu, 27 Apr 2006 13:52:40 -0400 In-Reply-To: (Ken Raeburn's message of "Wed, 26 Apr 2006 17:42:50 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: kitten@ietf.org Subject: Re: Charter: internationalization is out of scope X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org >>>>> "Ken" == Ken Raeburn writes: Ken> On Apr 26, 2006, at 17:34, Sam Hartman wrote: >> Note that if the WG does not work on internationalization, you >> will likely have trouble getting API drafts approved because >> they will not meet IETF internationalization requirements. Ken> If it's an IETF requirement, doesn't that implicitly put it Ken> in scope for any working group with a deliverable subject to Ken> that requirement, unless it's explicitly described as out of Ken> scope? Not quite. The IETF requirement will require anything you define now to be properly internationalized. However you cannot go back and change things in the spec unrelated to what you are working on. So, you might end up with something silly like name attributes being UTF8 but names being ISO 8859-1. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Apr 27 13:54:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZAgi-00066e-Vw; Thu, 27 Apr 2006 13:54:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZAgh-00066Y-M8 for kitten@ietf.org; Thu, 27 Apr 2006 13:53:59 -0400 Received: from carter-zimmerman.dyn.mit.edu ([18.188.3.148] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZAgg-0005OQ-GV for kitten@ietf.org; Thu, 27 Apr 2006 13:53:59 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 1C362E0053; Thu, 27 Apr 2006 13:53:56 -0400 (EDT) To: kitten@ietf.org References: <20060426221854.GM8152@binky.Central.Sun.COM> From: Sam Hartman Date: Thu, 27 Apr 2006 13:53:56 -0400 In-Reply-To: <20060426221854.GM8152@binky.Central.Sun.COM> (Nicolas Williams's message of "Wed, 26 Apr 2006 17:18:54 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Subject: Re: Charter: internationalization is out of scope X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> Simpler: I18N is out of scope, but GSS-APIv2u1 Nicolas> clarifications are in scope, which means that... Nicolas> ...we can clarify the locale/codeset issue while leaving Nicolas> Unicode-specific versions of GSS_Display_name(), Nicolas> GSS_Display_status() (which would also need localization, Nicolas> i.e., langtags) and GSS_Import_name() out of scope. Clarification does not mean changing the spec. You cannot change the spec from 8859-1 to current locale and call that a clarification. You can add an interoperability note saying that people do not follow the spec. That's not really sufficient long-term. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Apr 27 14:32:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZBHh-0005EJ-9w; Thu, 27 Apr 2006 14:32:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZBHg-0005EE-QU for kitten@ietf.org; Thu, 27 Apr 2006 14:32:12 -0400 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZBHe-0008AJ-B0 for kitten@ietf.org; Thu, 27 Apr 2006 14:32:12 -0400 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id k3RIW9if021564 for ; Thu, 27 Apr 2006 11:32:09 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id k3RIW7da016774 for ; Thu, 27 Apr 2006 12:32:09 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k3RIW3F5010360; Thu, 27 Apr 2006 13:32:03 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k3RIW3eq010359; Thu, 27 Apr 2006 13:32:03 -0500 (CDT) Date: Thu, 27 Apr 2006 13:32:03 -0500 From: Nicolas Williams To: Sam Hartman Message-ID: <20060427183202.GI8152@binky.Central.Sun.COM> Mail-Followup-To: Sam Hartman , kitten@ietf.org References: <20060426221854.GM8152@binky.Central.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: kitten@ietf.org Subject: Re: Charter: internationalization is out of scope X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Thu, Apr 27, 2006 at 01:53:56PM -0400, Sam Hartman wrote: > >>>>> "Nicolas" == Nicolas Williams writes: > > Nicolas> Simpler: I18N is out of scope, but GSS-APIv2u1 > Nicolas> clarifications are in scope, which means that... > > Nicolas> ...we can clarify the locale/codeset issue while leaving > Nicolas> Unicode-specific versions of GSS_Display_name(), > Nicolas> GSS_Display_status() (which would also need localization, > Nicolas> i.e., langtags) and GSS_Import_name() out of scope. > > > Clarification does not mean changing the spec. > > You cannot change the spec from 8859-1 to current locale and call that > a clarification. You can add an interoperability note saying that > people do not follow the spec. > That's not really sufficient long-term. I insist that the spec is *broken* and that *noone* implements what it says about this. (Martin hasn't yet confirmed that this is true of his apps/mechs. Martin?) _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Apr 27 15:05:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZBne-0001hv-Nt; Thu, 27 Apr 2006 15:05:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZBnd-0001hp-Qa for kitten@ietf.org; Thu, 27 Apr 2006 15:05:13 -0400 Received: from nwkea-mail-5.sun.com ([192.18.42.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZBnc-0001xX-BF for kitten@ietf.org; Thu, 27 Apr 2006 15:05:13 -0400 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-5.sun.com (8.12.10/8.12.9) with ESMTP id k3RJ5BaN008978 for ; Thu, 27 Apr 2006 12:05:11 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id k3RJ5Ada003817 for ; Thu, 27 Apr 2006 13:05:10 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k3RJ5AmT010371; Thu, 27 Apr 2006 14:05:10 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k3RJ5AtK010370; Thu, 27 Apr 2006 14:05:10 -0500 (CDT) Date: Thu, 27 Apr 2006 14:05:10 -0500 From: Nicolas Williams To: Martin Rex Message-ID: <20060427190509.GJ8152@binky.Central.Sun.COM> Mail-Followup-To: Martin Rex , kitten@ietf.org, hartmans-ietf@mit.edu References: <20060426223556.GO8152@binky.Central.Sun.COM> <200604271403.QAA20890@uw1048.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200604271403.QAA20890@uw1048.wdf.sap.corp> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: kitten@ietf.org, hartmans-ietf@mit.edu Subject: Re: Charter: internationalization is out of scope X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Thu, Apr 27, 2006 at 04:03:47PM +0200, Martin Rex wrote: > > Noone implements GSS-API mechglue that enforces the use of Latin-1 and > > noone implements GSS-API applications that convert between whatever > > codeset is used above to/from Latin-1 in the GSS-API calls. > > I have shipped code that relies on the strings to be iso-latin-1 > (because my code sends the printable name through the network, > and I did have EBCDIC and ASCII machines) This is not conclusive. Mechanism implementations that just-send-8 are a dime a dozen. That's not the issue here. Let's be much more specific: 1) Have you shipped any GSS-API C-bindings applications that explicitly convert text strings[0] used as input for gss_import_name() from some codeset[1] to ISO8859-1? 2) Have you shipped any libraries that use the GSS-API C-bindings and which explicitly convert text strings[2] from some codeset[1][3] to ISO8859-1? 3) Have you shipped any libraries that use the GSS-API C-bindings and which explicitly demand inputs that ultimately are to be passed to gss_import_name() to be in ISO8859-1? Or any other codeset? a) Do the applications that use any such libraries comply? 4) Have you shipped any mechanisms that explicitly convert gss_import_name() text inputs *from* ISO8859-1 to some other codeset, and which assume that gss_import_name() text inputs are always in ISO8859-1 encoding? a) Do the applications that use such mechanisms comply? Or do they work only in Latin-1 locales? Or only for US-ASCII text? (1), (2), (3), (3a) are all about what applications do, including libraries as applications, as well as consumers thereof. If the answers to (1) or (2) are "yes," then we can't do what I propose or any variant thereof. If the answers to (3) _and_ (3a) are "yes," then we can't do what I propose or any variant thereof. If the answers to (4) _and_ (4a) are "yes," then we can't do what I propose or any variant thereof. Have I missed any other relevant questions? [0] provided by users, config files, ... [1] presumably whatever the input method/current locale used [2] provided by applications, users, config files, ... [3] possibly defined by the library's interface specification Cheers, Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Apr 27 17:13:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZDnM-0000gr-95; Thu, 27 Apr 2006 17:13:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZDnL-0000gm-Iu for kitten@ietf.org; Thu, 27 Apr 2006 17:13:03 -0400 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZDnL-00032H-4z for kitten@ietf.org; Thu, 27 Apr 2006 17:13:03 -0400 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id XAA12985; Thu, 27 Apr 2006 23:13:00 +0200 (MESZ) From: Martin Rex Message-Id: <200604272112.XAA28182@uw1048.wdf.sap.corp> To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Thu, 27 Apr 2006 23:12:59 +0200 (MET DST) In-Reply-To: <20060427190509.GJ8152@binky.Central.Sun.COM> from "Nicolas Williams" at Apr 27, 6 02:05:10 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: kitten@ietf.org, hartmans-ietf@mit.edu Subject: Re: Charter: internationalization is out of scope X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org Nicolas Williams wrote: > > On Thu, Apr 27, 2006 at 04:03:47PM +0200, Martin Rex wrote: > > > Noone implements GSS-API mechglue that enforces the use of Latin-1 and > > > noone implements GSS-API applications that convert between whatever > > > codeset is used above to/from Latin-1 in the GSS-API calls. > > > > I have shipped code that relies on the strings to be iso-latin-1 > > (because my code sends the printable name through the network, > > and I did have EBCDIC and ASCII machines) > > This is not conclusive. > > Mechanism implementations that just-send-8 are a dime a dozen. That's > not the issue here. Two things: We have been (and still are) shipping a(n OEM) gssapi mechanism that that is similar to SPKM1 and uses X.509 certificates for authentication and exclusively uses ISO-Latin-1 on ASCII-platforms for all printable strings at the GSS-API level (independent of locale). Characters outside of ISO-Latin-1 are represented with "\uNNNN" unicode codepoints. That software implements T61STRING within distinguished names according to the original spec and some customers were suprized when illegally encoded ISO-Latin-1 characters in their certs were visualized differently to what they expected. In my (network) protocol layer I transfer the target name along in the protocol framing around the context establishment token and it used ISO-Latin-1 transfer encoding (this is what EBCDIC components of my software will expect) and it de-facto relies on the gssapi mechanism that our application calls to provide/use ISO-Latin-1 for names. In most scenarios, this name will only be used if context establishment fails to check whether there's a mismatch between the target name used by the initiator and the credentials owner of the acceptor to return a meaningful error message back to the initiator (along with the real name of the acceptor). This mainly affects names of acceptors/servers, which usually have less need for non-ASCII chars in their names and are much easier to re-personalize (in particular for flag-day changes) if it should be necessary than a large user base. There's one particular situation where an acceptor can be started without knowing the name of it's accepting credentials, and when it receives a the initial context level token, it will use the target name supplied by the initiator, and try to acquire credentials for that name and use it to accept the incoming security context. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Apr 27 17:38:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZEBZ-00036y-9e; Thu, 27 Apr 2006 17:38:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZEBY-00036t-9J for kitten@ietf.org; Thu, 27 Apr 2006 17:38:04 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZEBV-0004R6-RW for kitten@ietf.org; Thu, 27 Apr 2006 17:38:04 -0400 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id k3RLc18x017299 for ; Thu, 27 Apr 2006 15:38:01 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id k3RLc0da003930 for ; Thu, 27 Apr 2006 15:38:00 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k3RLc09T013058; Thu, 27 Apr 2006 16:38:00 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k3RLbxNh013057; Thu, 27 Apr 2006 16:37:59 -0500 (CDT) Date: Thu, 27 Apr 2006 16:37:59 -0500 From: Nicolas Williams To: Martin Rex Message-ID: <20060427213758.GH12709@binky.Central.Sun.COM> Mail-Followup-To: Martin Rex , kitten@ietf.org, hartmans-ietf@mit.edu References: <20060427190509.GJ8152@binky.Central.Sun.COM> <200604272112.XAA28182@uw1048.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200604272112.XAA28182@uw1048.wdf.sap.corp> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: kitten@ietf.org, hartmans-ietf@mit.edu Subject: Re: Charter: internationalization is out of scope X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Thu, Apr 27, 2006 at 11:12:59PM +0200, Martin Rex wrote: > Two things: > > We have been (and still are) shipping a(n OEM) gssapi mechanism that > that is similar to SPKM1 and uses X.509 certificates for authentication > and exclusively uses ISO-Latin-1 on ASCII-platforms for all printable > strings at the GSS-API level (independent of locale). Characters > outside of ISO-Latin-1 are represented with "\uNNNN" unicode codepoints. Do the applications using this mechanism convert from whatever codeset they have to ISO8859-1? If not, does this mean that they only work in ISO8859-1 locales or for US-ASCII codepoints only? Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Apr 27 18:10:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZEgy-0000DN-Uk; Thu, 27 Apr 2006 18:10:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZEgw-0000DI-Uz for kitten@ietf.org; Thu, 27 Apr 2006 18:10:30 -0400 Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZEgv-0007cH-Gq for kitten@ietf.org; Thu, 27 Apr 2006 18:10:30 -0400 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id AAA25229; Fri, 28 Apr 2006 00:10:24 +0200 (MESZ) From: Martin Rex Message-Id: <200604272210.AAA28938@uw1048.wdf.sap.corp> To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Fri, 28 Apr 2006 00:10:24 +0200 (MET DST) In-Reply-To: <20060427213758.GH12709@binky.Central.Sun.COM> from "Nicolas Williams" at Apr 27, 6 04:37:59 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: kitten@ietf.org, hartmans-ietf@mit.edu Subject: Re: Charter: internationalization is out of scope X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org Nicolas Williams wrote: > > On Thu, Apr 27, 2006 at 11:12:59PM +0200, Martin Rex wrote: > > Two things: > > > > We have been (and still are) shipping a(n OEM) gssapi mechanism that > > that is similar to SPKM1 and uses X.509 certificates for authentication > > and exclusively uses ISO-Latin-1 on ASCII-platforms for all printable > > strings at the GSS-API level (independent of locale). Characters > > outside of ISO-Latin-1 are represented with "\uNNNN" unicode codepoints. > > Do the applications using this mechanism convert from whatever codeset > they have to ISO8859-1? If not, does this mean that they only work in > ISO8859-1 locales or for US-ASCII codepoints only? There are different levels of usage in our application. :) It is a distributed application, and it was possible (and used) that one could run AppServers with different codepages and all printable data (which could include printable names in ACLs) are codepage-converted when transfered between to Servers working with different codepages. My intermediate communication protocol layer strictly relies on names being ISO-latin-1, but in most installations it didn't show, because the codepage conversion that is performed is the identity operation. Our "upper" application layer traditionally used "just-use-8" with what-ever codepage is configured for our APP (but our APPs notion is seperate from the systems notion of the OS locale and also independent of the database locale). However, a while ago our "upper" application layers changed to use UCS2 internally, so I had to add a conversion. The current codepage conversion that is performed is ISO-Latin-1 -> UCS2 and (due to a bug...) UCS2-> ASCII 7-bit with '#' for chars that cannot be represented. A customer in Korea which has been taking advantage of the "lack of conversion" in the single-byte App was surprised that this no longer worked in the new Unicode variant of our app. A lot of people (unfortunately also a lot of software engineers) have the illusion that changing an application from single byte to unicode will improve things, while in reality it significantly impairs things in all areas where legacy code/APIs is involved, because all of the situations where people were taking advantage of "just-use-8"/"just-send-8" suddenly no longer work. During 1999-2000 I told our Unicode-pushers here that this problem would come up with our customers one day on every occasion when I saw them, and suggested that they should fight for the necessary resources to design a solution ahead of time, but they decided to ignore me. I put on a big smile when they came with the customer problem a few weeks ago ("told you so"). But besides trying to provide a fix that brings back the behaviour of the single-byte application, I will likely have to design a reliable solution for the problem to support full Unicode, which requires UTF-8 at the GSS-API level and which is independent of the OS locale. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Apr 27 18:20:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZEqE-0000yK-4n; Thu, 27 Apr 2006 18:20:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZEqC-0000w5-KS for kitten@ietf.org; Thu, 27 Apr 2006 18:20:04 -0400 Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZEqB-0008IS-8t for kitten@ietf.org; Thu, 27 Apr 2006 18:20:04 -0400 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id AAA02648; Fri, 28 Apr 2006 00:19:56 +0200 (MESZ) From: Martin Rex Message-Id: <200604272219.AAA29036@uw1048.wdf.sap.corp> To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Fri, 28 Apr 2006 00:19:56 +0200 (MET DST) In-Reply-To: <20060427153219.GD8152@binky.Central.Sun.COM> from "Nicolas Williams" at Apr 27, 6 10:32:19 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: kitten@ietf.org, hartmans-ietf@mit.edu Subject: Re: Charter: internationalization is out of scope X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org Nicolas Williams wrote: > > On Thu, Apr 27, 2006 at 11:28:43AM -0400, Jeffrey Altman wrote: > > Jeffrey Hutzelman wrote: > > > (2) Nico's point is that the spec is broken because what it describes > > > is not what any of the implementations actually _do_. > > > > The fact that the implementors that we know about do not output > > Latin-1 does not make the spec broken. It means that the implementors > > didn't read it correctly when they wrote their code OR intentionally > > chose to do something in violation of the spec. > > Noone in their right mind will implement what the spec says in this > case. I dare MIT to do it ;) -- I know MIT won't, because MIT isn't > insane. I'm sorry, I strongly disagree. HTTP originally used ISO-Latin-1 exclusively, and quite a lot of Browser and Server software implemented it correctly. And I don't remember people constantly complaining that the selection/use of ISO-Latin-1 was *broken*. It was a deliberate choice from someone working in Switzerland who didn't have the focus on standards when he started, but rather the ease of use and implementation with the immediate need to represent certain accented characters from the ISO-Latin-1 charset. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Apr 27 18:27:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZEx1-0008SV-DV; Thu, 27 Apr 2006 18:27:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZEx0-0008SB-ME for kitten@ietf.org; Thu, 27 Apr 2006 18:27:06 -0400 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZEx0-0000L1-BR for kitten@ietf.org; Thu, 27 Apr 2006 18:27:06 -0400 Received: from centralmail1brm.Central.Sun.COM (centralmail1brm.central.sun.com [129.147.62.1]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id k3RMR54d023588 for ; Thu, 27 Apr 2006 16:27:05 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id k3RMR5ca006657 for ; Thu, 27 Apr 2006 16:27:05 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k3RMR49Y013189; Thu, 27 Apr 2006 17:27:04 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k3RMR4Vq013188; Thu, 27 Apr 2006 17:27:04 -0500 (CDT) Date: Thu, 27 Apr 2006 17:27:04 -0500 From: Nicolas Williams To: Martin Rex Message-ID: <20060427222704.GI12709@binky.Central.Sun.COM> Mail-Followup-To: Martin Rex , kitten@ietf.org, hartmans-ietf@mit.edu References: <20060427213758.GH12709@binky.Central.Sun.COM> <200604272210.AAA28938@uw1048.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200604272210.AAA28938@uw1048.wdf.sap.corp> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: kitten@ietf.org, hartmans-ietf@mit.edu Subject: Re: Charter: internationalization is out of scope X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Fri, Apr 28, 2006 at 12:10:24AM +0200, Martin Rex wrote: > My intermediate communication protocol layer strictly relies on names > being ISO-latin-1, but in most installations it didn't show, because > the codepage conversion that is performed is the identity operation. > Our "upper" application layer traditionally used "just-use-8" with > what-ever codepage is configured for our APP (but our APPs notion > is seperate from the systems notion of the OS locale and also > independent of the database locale). > > However, a while ago our "upper" application layers changed to use > UCS2 internally, so I had to add a conversion. The current codepage > conversion that is performed is ISO-Latin-1 -> UCS2 and > (due to a bug...) UCS2-> ASCII 7-bit with '#' for chars that > cannot be represented. OK, so you do implement the Latin-1 part of the spec. From what you write you did not start out doing it the way the spec said in your apps, but did in your mechs, and ended up fixing the apps to meet the spec also. I soooo wish you'd done it the reasonable way to begin with, I soooo wish IETF I18N experience had been more advanced at the time the C bindings were standardized. Fine. Then I see only one way out: - deprecate gss_import_name() (for anything other than GSS_C_NT_EXPORTER_NAME at least), gss_display_name, and, possibly, depending on what you apps and mechs do with it, gss_display_status() Why? Because other implementors have an installed base such that switching to being compliant with the spec on this would be backwards-incompatible and anyways, we need more than Latin-1. - issue replacements that do what rfc2744 should have said (just-use-8 -- note: not just-send-8)... ...but, to make it easy for developers on platforms that have facilities that deal exclusively in UTF-8 even when the current locale is not a UTF-8 locale, I'd agree to a parameter for selecting a character encoding scheme with two possible values: GSS_C_CES_DEFAULT (e.g., current locale's), and GSS_C_CES_UTF8. *sigh* Very disappointed, Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Apr 27 18:37:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZF76-000427-7x; Thu, 27 Apr 2006 18:37:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZF75-00041x-Ce for kitten@ietf.org; Thu, 27 Apr 2006 18:37:31 -0400 Received: from chokecherry.srv.cs.cmu.edu ([128.2.185.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZF74-0000Y1-4k for kitten@ietf.org; Thu, 27 Apr 2006 18:37:31 -0400 Received: from sirius.fac.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.5/8.13.5) with ESMTP id k3RMbPZL016827 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 27 Apr 2006 18:37:25 -0400 (EDT) Date: Thu, 27 Apr 2006 18:37:25 -0400 From: Jeffrey Hutzelman To: Nicolas Williams , Martin Rex Message-ID: In-Reply-To: <20060427222704.GI12709@binky.Central.Sun.COM> References: <20060427213758.GH12709@binky.Central.Sun.COM> <200604272210.AAA28938@uw1048.wdf.sap.corp> <20060427222704.GI12709@binky.Central.Sun.COM> Originator-Info: login-token=Mulberry:01VgYgfsBulfKiUZj/iYRQ7e14V6ndOpnDe07jjIY=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: kitten@ietf.org, hartmans-ietf@mit.edu Subject: Re: Charter: internationalization is out of scope X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Thursday, April 27, 2006 05:27:04 PM -0500 Nicolas Williams wrote: > On Fri, Apr 28, 2006 at 12:10:24AM +0200, Martin Rex wrote: >> My intermediate communication protocol layer strictly relies on names >> being ISO-latin-1, but in most installations it didn't show, because >> the codepage conversion that is performed is the identity operation. >> Our "upper" application layer traditionally used "just-use-8" with >> what-ever codepage is configured for our APP (but our APPs notion >> is seperate from the systems notion of the OS locale and also >> independent of the database locale). >> >> However, a while ago our "upper" application layers changed to use >> UCS2 internally, so I had to add a conversion. The current codepage >> conversion that is performed is ISO-Latin-1 -> UCS2 and >> (due to a bug...) UCS2-> ASCII 7-bit with '#' for chars that >> cannot be represented. > > OK, so you do implement the Latin-1 part of the spec. From what you > write you did not start out doing it the way the spec said in your apps, > but did in your mechs, and ended up fixing the apps to meet the spec > also. I soooo wish you'd done it the reasonable way to begin with, I > soooo wish IETF I18N experience had been more advanced at the time the C > bindings were standardized. > > Fine. Then I see only one way out: > > - deprecate gss_import_name() (for anything other than > GSS_C_NT_EXPORTER_NAME at least), gss_display_name, and, possibly, > depending on what you apps and mechs do with it, gss_display_status() > > Why? Because other implementors have an installed base such that > switching to being compliant with the spec on this would be > backwards-incompatible and anyways, we need more than Latin-1. > > - issue replacements that do what rfc2744 should have said (just-use-8 > -- note: not just-send-8)... > > ...but, to make it easy for developers on platforms that have > facilities that deal exclusively in UTF-8 even when the current > locale is not a UTF-8 locale, I'd agree to a parameter for selecting > a character encoding scheme with two possible values: > GSS_C_CES_DEFAULT (e.g., current locale's), and GSS_C_CES_UTF8. This is clearly beyond the realm of "clarifications". At this point I think Jeff is right; the only clarification we can do to GSSAPIv2u1 is to add an implementation note indicating there are a lot of implementations that just-use-8 instead of doing what the spec says. For GSSAPIv3, we can eliminate the 8859-1 interfaces in favor of interfaces that use UTF-8. -- Jeff _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Apr 27 18:52:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZFLL-0002XY-6T; Thu, 27 Apr 2006 18:52:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZFLJ-0002XL-Oq for kitten@ietf.org; Thu, 27 Apr 2006 18:52:13 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZFLI-0000tl-Bl for kitten@ietf.org; Thu, 27 Apr 2006 18:52:13 -0400 Received: from centralmail1brm.Central.Sun.COM (centralmail1brm.central.sun.com [129.147.62.1]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id k3RMqBaN004117 for ; Thu, 27 Apr 2006 16:52:12 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id k3RMqAcc016327 for ; Thu, 27 Apr 2006 16:52:11 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k3RMqA4E013312; Thu, 27 Apr 2006 17:52:10 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k3RMqAvK013311; Thu, 27 Apr 2006 17:52:10 -0500 (CDT) Date: Thu, 27 Apr 2006 17:52:10 -0500 From: Nicolas Williams To: Martin Rex Message-ID: <20060427225209.GJ12709@binky.Central.Sun.COM> Mail-Followup-To: Martin Rex , jaltman@columbia.edu, kitten@ietf.org, hartmans-ietf@mit.edu References: <20060427153219.GD8152@binky.Central.Sun.COM> <200604272219.AAA29036@uw1048.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200604272219.AAA29036@uw1048.wdf.sap.corp> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: kitten@ietf.org, hartmans-ietf@mit.edu Subject: Re: Charter: internationalization is out of scope X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Fri, Apr 28, 2006 at 12:19:56AM +0200, Martin Rex wrote: > Nicolas Williams wrote: > > Noone in their right mind will implement what the spec says in this > > case. I dare MIT to do it ;) -- I know MIT won't, because MIT isn't > > insane. > > I'm sorry, I strongly disagree. Well, you did implement that part of the spec, but noone else will now unless they have to use your mechanisms or be used by your apps. > HTTP originally used ISO-Latin-1 exclusively, and quite a lot > of Browser and Server software implemented it correctly. > > And I don't remember people constantly complaining that the selection/use > of ISO-Latin-1 was *broken*. It was a deliberate choice from someone > working in Switzerland who didn't have the focus on standards when > he started, but rather the ease of use and implementation with > the immediate need to represent certain accented characters from > the ISO-Latin-1 charset. What's broken is requiring that the application do codeset conversions here. The choice of CES was poor too, particularly considering that choosing one of the ISO8859 codesets to the exclusion of the others screwed everyone else. BUT, that's just par for the course for lots of systems and protocols older than just a few years, and therfore very much forgivable. Most OS vendors, such as my employer, are still dealing with the fact that Unicode didn't exist back in the 1970s (the world of computer science then was not sufficiently globalized), so this is just one more thing to fix. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Apr 27 18:54:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZFNM-0004BP-0C; Thu, 27 Apr 2006 18:54:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZFNK-0004Ah-TV for kitten@ietf.org; Thu, 27 Apr 2006 18:54:18 -0400 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZFNK-00012v-GH for kitten@ietf.org; Thu, 27 Apr 2006 18:54:18 -0400 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id AAA07797; Fri, 28 Apr 2006 00:54:15 +0200 (MESZ) From: Martin Rex Message-Id: <200604272254.AAA29697@uw1048.wdf.sap.corp> To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Fri, 28 Apr 2006 00:54:14 +0200 (MET DST) In-Reply-To: <20060427222704.GI12709@binky.Central.Sun.COM> from "Nicolas Williams" at Apr 27, 6 05:27:04 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: kitten@ietf.org, hartmans-ietf@mit.edu Subject: Re: Charter: internationalization is out of scope X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org Nicolas Williams wrote: > > On Fri, Apr 28, 2006 at 12:10:24AM +0200, Martin Rex wrote: > > My intermediate communication protocol layer strictly relies on names > > being ISO-latin-1, but in most installations it didn't show, because > > the codepage conversion that is performed is the identity operation. > > Our "upper" application layer traditionally used "just-use-8" with > > what-ever codepage is configured for our APP (but our APPs notion > > is seperate from the systems notion of the OS locale and also > > independent of the database locale). > > > > However, a while ago our "upper" application layers changed to use > > UCS2 internally, so I had to add a conversion. The current codepage > > conversion that is performed is ISO-Latin-1 -> UCS2 and > > (due to a bug...) UCS2-> ASCII 7-bit with '#' for chars that > > cannot be represented. > > OK, so you do implement the Latin-1 part of the spec. From what you > write you did not start out doing it the way the spec said in your apps, > but did in your mechs, and ended up fixing the apps to meet the spec > also. I soooo wish you'd done it the reasonable way to begin with, I > soooo wish IETF I18N experience had been more advanced at the time the C > bindings were standardized. Sorry, but the GSS-API spec is more reasonable than the "just-use-8" implementations. The problem that we have today is by implementors ignoring the spec instead of complaining instead of producing an updated spec that solves the problem in a clean fashion. > > Fine. Then I see only one way out: > > - deprecate gss_import_name() (for anything other than > GSS_C_NT_EXPORTER_NAME at least), gss_display_name, and, possibly, > depending on what you apps and mechs do with it, gss_display_status() > > Why? Because other implementors have an installed base such that > switching to being compliant with the spec on this would be > backwards-incompatible and anyways, we need more than Latin-1. The GSS-API v2 spec isn't broken, and there is no problem for installations that had either been using full ISO-Latin-1 or pure 7-bit ASCII names with an arbitrary single or multi-byte codepage that has ASCII in the lower 128 codepoints. > > - issue replacements that do what rfc2744 should have said (just-use-8 > -- note: not just-send-8)... As the security context establishent involves token exchanges that will at least transfer the name of the initiator to the acceptor side, and sometimes involve names created by a third party (KDC or CA), we will have to document it as "just-use-8" plus "just-send-8". > > ...but, to make it easy for developers on platforms that have > facilities that deal exclusively in UTF-8 even when the current > locale is not a UTF-8 locale, I'd agree to a parameter for selecting > a character encoding scheme with two possible values: > GSS_C_CES_DEFAULT (e.g., current locale's), and GSS_C_CES_UTF8. There is a certain problem with multi-bytes including UTF-8 already: look at how the hostbased service name is defined. It is specified as being composed of a servicename part and a hostname part, glued together with an ASCII "@" sign. So there may be a problem today with multi-bytes when a "just-use-8" name parser searches for "@" without knowlegde that a multi-byte codepage (and not a single-byte codepage) is used, as I understand it. This search might accidentally pick the trail byte 0x40 of a multibyte character instead of the real 0x40 ASCII char. This does affect the internal Kerberos principal name parsing and the '/' character as well! You can not safely certain characters from certain multibyte locales with "just-use-8" Kerberos implementations today even with the native Kerberos APIs. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Apr 27 18:57:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZFQf-0005rQ-9v; Thu, 27 Apr 2006 18:57:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZFQd-0005rL-Hk for kitten@ietf.org; Thu, 27 Apr 2006 18:57:43 -0400 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZFQc-0001A0-1s for kitten@ietf.org; Thu, 27 Apr 2006 18:57:43 -0400 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id k3RMvf3i018056 for ; Thu, 27 Apr 2006 16:57:41 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id k3RMvedc010981 for ; Thu, 27 Apr 2006 16:57:41 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k3RMsIVR013321; Thu, 27 Apr 2006 17:54:18 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k3RMsIQO013320; Thu, 27 Apr 2006 17:54:18 -0500 (CDT) Date: Thu, 27 Apr 2006 17:54:18 -0500 From: Nicolas Williams To: Jeffrey Hutzelman Message-ID: <20060427225417.GK12709@binky.Central.Sun.COM> Mail-Followup-To: Jeffrey Hutzelman , Martin Rex , kitten@ietf.org, hartmans-ietf@mit.edu References: <20060427213758.GH12709@binky.Central.Sun.COM> <200604272210.AAA28938@uw1048.wdf.sap.corp> <20060427222704.GI12709@binky.Central.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: kitten@ietf.org, hartmans-ietf@mit.edu Subject: Re: Charter: internationalization is out of scope X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Thu, Apr 27, 2006 at 06:37:25PM -0400, Jeffrey Hutzelman wrote: > On Thursday, April 27, 2006 05:27:04 PM -0500 Nicolas Williams > wrote: > >Fine. Then I see only one way out: > > This is clearly beyond the realm of "clarifications". At this point I > think Jeff is right; the only clarification we can do to GSSAPIv2u1 is to > add an implementation note indicating there are a lot of implementations > that just-use-8 instead of doing what the spec says. Yes. > For GSSAPIv3, we can eliminate the 8859-1 interfaces in favor of interfaces > that use UTF-8. No, we need at least an option for "just-use-8," a.k.a., "just-use-the-current-locale's-ces," because I don't want to have to change aplications to do codeset conversions if I can avoid it. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Apr 27 19:13:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZFfr-00013q-M2; Thu, 27 Apr 2006 19:13:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZFfn-0000Yo-7j for kitten@ietf.org; Thu, 27 Apr 2006 19:13:23 -0400 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZFTY-0001E1-SZ for kitten@ietf.org; Thu, 27 Apr 2006 19:00:46 -0400 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id k3RN0iif002925 for ; Thu, 27 Apr 2006 16:00:44 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id k3RN0gda012608 for ; Thu, 27 Apr 2006 17:00:43 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k3RMusMn013330; Thu, 27 Apr 2006 17:56:54 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k3RMus48013329; Thu, 27 Apr 2006 17:56:54 -0500 (CDT) Date: Thu, 27 Apr 2006 17:56:54 -0500 From: Nicolas Williams To: Martin Rex Message-ID: <20060427225654.GL12709@binky.Central.Sun.COM> Mail-Followup-To: Martin Rex , kitten@ietf.org, hartmans-ietf@mit.edu References: <20060427222704.GI12709@binky.Central.Sun.COM> <200604272254.AAA29697@uw1048.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200604272254.AAA29697@uw1048.wdf.sap.corp> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: kitten@ietf.org, hartmans-ietf@mit.edu Subject: Re: Charter: internationalization is out of scope X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Fri, Apr 28, 2006 at 12:54:14AM +0200, Martin Rex wrote: > Nicolas Williams wrote: > > - issue replacements that do what rfc2744 should have said (just-use-8 > > -- note: not just-send-8)... > > As the security context establishent involves token exchanges that > will at least transfer the name of the initiator to the acceptor side, > and sometimes involve names created by a third party (KDC or CA), > we will have to document it as "just-use-8" plus "just-send-8". NO. What the mechanism sends is up to the mechanism's spec. It so happens that many implementations of the Kerberos V GSS-API mechanism just-send-8. BUT, just-use-8 at the API does not condemn mechanisms to just-send-8. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Apr 27 19:13:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZFfu-0001IE-6h; Thu, 27 Apr 2006 19:13:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZFfd-0000Yo-9q for kitten@ietf.org; Thu, 27 Apr 2006 19:13:13 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZFa7-0001io-85 for kitten@ietf.org; Thu, 27 Apr 2006 19:07:32 -0400 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id k3RN7U8x000273 for ; Thu, 27 Apr 2006 17:07:30 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id k3RN7Tda018264 for ; Thu, 27 Apr 2006 17:07:29 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k3RN3dW7013346; Thu, 27 Apr 2006 18:03:39 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k3RN3d9L013345; Thu, 27 Apr 2006 18:03:39 -0500 (CDT) Date: Thu, 27 Apr 2006 18:03:39 -0500 From: Nicolas Williams To: Martin Rex Message-ID: <20060427230339.GM12709@binky.Central.Sun.COM> Mail-Followup-To: Martin Rex , kitten@ietf.org, hartmans-ietf@mit.edu References: <20060427222704.GI12709@binky.Central.Sun.COM> <200604272254.AAA29697@uw1048.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200604272254.AAA29697@uw1048.wdf.sap.corp> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: kitten@ietf.org, hartmans-ietf@mit.edu Subject: Re: Charter: internationalization is out of scope X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Fri, Apr 28, 2006 at 12:54:14AM +0200, Martin Rex wrote: > There is a certain problem with multi-bytes including UTF-8 already: > look at how the hostbased service name is defined. It is specified > as being composed of a servicename part and a hostname part, glued > together with an ASCII "@" sign. So there may be a problem today > with multi-bytes when a "just-use-8" name parser searches for "@" > without knowlegde that a multi-byte codepage (and not a single-byte > codepage) is used, as I understand it. "just-use-8" in these API slots means "just-use-the-current-locale's-ces." Which means that properly implemented mechanisms need not run into this problem. Forcing applications to convert these inputs/outputs to/from UTF-8 is quite obnoxious. Forcing the mechanisms to do the conversions, which they have to be prepared to do anyways because they should not just-send-8, means less code has to do these conversions, which I think is a very good result. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Apr 27 19:19:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZFlP-0007sK-61; Thu, 27 Apr 2006 19:19:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZFlN-0007sF-CQ for kitten@ietf.org; Thu, 27 Apr 2006 19:19:09 -0400 Received: from chokecherry.srv.cs.cmu.edu ([128.2.185.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZFlN-00039u-4J for kitten@ietf.org; Thu, 27 Apr 2006 19:19:09 -0400 Received: from sirius.fac.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.5/8.13.5) with ESMTP id k3RNJ7du017421 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 27 Apr 2006 19:19:07 -0400 (EDT) Date: Thu, 27 Apr 2006 19:19:07 -0400 From: Jeffrey Hutzelman To: martin.rex@sap.com, Nicolas Williams Message-ID: <5DEEE4B27EC0AF1733A1E014@sirius.fac.cs.cmu.edu> In-Reply-To: <200604272254.AAA29697@uw1048.wdf.sap.corp> References: <200604272254.AAA29697@uw1048.wdf.sap.corp> Originator-Info: login-token=Mulberry:010XQI1jvcfUodv4BXBPI4RWjmPwFYqIE+6TY7B/Q=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: kitten@ietf.org, hartmans-ietf@mit.edu Subject: Re: Charter: internationalization is out of scope X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Friday, April 28, 2006 12:54:14 AM +0200 Martin Rex wrote: > The GSS-API v2 spec isn't broken, and there is no problem for > installations that had either been using full ISO-Latin-1 or > pure 7-bit ASCII names with an arbitrary single or multi-byte codepage > that has ASCII in the lower 128 codepoints. It is broken, because it excludes characters which cannot be represented in iso-8859-1. Now, that turns out not to be a problem for mechanisms which don't support more than US-ASCII anyway (for example, RFC4120-compliant Kerberos). It's also not a problem for mechanisms which define a funny escaping mechanism to represent non-8859-1 characters across the API, except that then the application has to know about the funny mapping, which is mechanism-specific and _not_ part of the GSS-API. The GSS-API v2 simply does not admit names which cannot be represented in ISO-8859-1. I consider that a bug, and I think it's unfortunate that we can't fix it in v2, but it's become clear that we cannot. >> - issue replacements that do what rfc2744 should have said (just-use-8 >> -- note: not just-send-8)... > > As the security context establishent involves token exchanges that > will at least transfer the name of the initiator to the acceptor side, > and sometimes involve names created by a third party (KDC or CA), > we will have to document it as "just-use-8" plus "just-send-8". No; what mechanisms do over the wire is up to the mechanism designer. That's _why_ we have a well-defined API, so that neither the API nor the application has to deal with mechanism specifics. If the API spec says 8859-1 and a mechanism uses something else on the wire, then it is up to the mechanism to convert from 8859-1 to its wire format and back. The same is true if the API spec says UTF-8, and the same is true if the API spec says "use whatever the current locale specifies" - you have to assume that things on both sides of the API know what "the current locale" is, but that still doesn't affect the wire or the guy at the other end of the connection, because the wire protocol still has to be whatever the mechanism said the wire protocol is going to be. For RFC4120/4121, names on the wire are US-ASCII, period. For RFC1510ter they will be UTF-8, period. If we end up updating RFC4121 for RFC1510ter and expect to use it under GSS-APIv2u1, then the mechanism will have to convert Latin-1 in the API to UTF-8 on the wire and back, and names that can't be representeed in Latin-1 will just not work. We're only talking about "just-use-8", in the API. The wire protocol is up to the mechanism. > There is a certain problem with multi-bytes including UTF-8 already: > look at how the hostbased service name is defined. It is specified > as being composed of a servicename part and a hostname part, glued > together with an ASCII "@" sign. So there may be a problem today > with multi-bytes when a "just-use-8" name parser searches for "@" > without knowlegde that a multi-byte codepage (and not a single-byte > codepage) is used, as I understand it. If you use arbitrary multi-byte encodings, you may have that problem. However, no one's suggesting using arbitrary encodings; we're talking about using UTF-8, which the IETF has selected as its standard character set and encoding. The UTF-8 encoding is carefully designed so it does not have this problem; an octet in the range 0x00-0x7f in a UTF-8 string _always_ stands for itself; multi-byte sequences always have the high bit set in every byte of the sequence. -- Jeff _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Apr 27 19:34:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZG06-0005gP-4Q; Thu, 27 Apr 2006 19:34:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZG04-0005fe-M8 for kitten@ietf.org; Thu, 27 Apr 2006 19:34:20 -0400 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZG04-0003uN-8b for kitten@ietf.org; Thu, 27 Apr 2006 19:34:20 -0400 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id BAB05123; Fri, 28 Apr 2006 01:34:13 +0200 (MESZ) From: Martin Rex Message-Id: <200604272334.BAA00246@uw1048.wdf.sap.corp> To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Fri, 28 Apr 2006 01:34:12 +0200 (MET DST) In-Reply-To: <20060427225209.GJ12709@binky.Central.Sun.COM> from "Nicolas Williams" at Apr 27, 6 05:52:10 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: kitten@ietf.org, hartmans-ietf@mit.edu Subject: Re: Charter: internationalization is out of scope X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org Nicolas Williams wrote: > > On Fri, Apr 28, 2006 at 12:19:56AM +0200, Martin Rex wrote: > > Nicolas Williams wrote: > > > Noone in their right mind will implement what the spec says in this > > > case. I dare MIT to do it ;) -- I know MIT won't, because MIT isn't > > > insane. > > > > I'm sorry, I strongly disagree. > > Well, you did implement that part of the spec, but noone else will now > unless they have to use your mechanisms or be used by your apps. I'm not the only one! The OEM library which we ship is also available as a Single Sign-On tool from its vendor, and it is based on a PKI toolkit that has used ISO-Latin-1 at all of its API calls long before I started working for my current company and got involved with GSS-API v2 standardization. Actually, here is an Email from John Wray (the author of both GSS-API v1 and v2 C-bindings documents rfc1509 and rfc2744) on this issue: : : Date: Tue, 23 Jan 96 11:05:35 EST : From: "John Wray, Digital DPE, (508) 486-5210 23-Jan-1996 1026" : To: marc@mit.edu : Cc: "cat-ietf@mit.edu"@in.ENET.dec.com, wray@tuxedo.ENET.dec.com : Subject: Re: question on draft-ietf-cat-gssv2-cbind-01 [...] : : ii) possible future I18N support. Today's GSSAPI assumes that character : strings are simple ISO-latin1 strings. At some time in the future, we may : want to support alternate character sets, using either multi-byte or wide : characters. Names are the most likely target for I18N, and APIs that support : extended character sets should behave as similar as possible to the regular : ISO-latin1 versions. NUL-termination doesn't work with wide characters. So the choice of ISO-Latin-1 wasn't accidental -- and it definitely isn't broken. "just-use-8" that is truely broken. > > What's broken is requiring that the application do codeset conversions > here. The choice of CES was poor too, particularly considering that > choosing one of the ISO8859 codesets to the exclusion of the others > screwed everyone else. BUT, that's just par for the course for lots of > systems and protocols older than just a few years, and therfore very > much forgivable. Most OS vendors, such as my employer, are still > dealing with the fact that Unicode didn't exist back in the 1970s (the > world of computer science then was not sufficiently globalized), so this > is just one more thing to fix. Allowing the use to freely choose a locale requires applications to perform codeset conversions, otherwise run into all kinds of interoperability problems. It may *appear* to work within small areas, but the simple proof that most of the time it doesn't is to change the locale and look at the data again -- if it looks different with a different locale, then it is obvious that locales are not supported. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Fri Apr 28 12:32:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZVsz-0004qY-4O; Fri, 28 Apr 2006 12:32:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZVsx-0004qQ-VA for kitten@ietf.org; Fri, 28 Apr 2006 12:32:03 -0400 Received: from stratton-four-eighty-five.mit.edu ([18.187.6.230] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZVsv-0004H1-OR for kitten@ietf.org; Fri, 28 Apr 2006 12:32:03 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 99849E0053; Fri, 28 Apr 2006 12:32:00 -0400 (EDT) To: kitten@ietf.org From: Sam Hartman Date: Fri, 28 Apr 2006 12:32:00 -0400 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Subject: Off in the weeds X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org Speaking mostly as an individual, although as an AD, I do think the current discussion is way out of scope. Folks, I think we've gotten off in the weeds with this internationalization discussion. I'd really like to take a step back and calm down. First, it's out of scope for now. Jeff wants to get other work done first. Jeff agreed with him and no one disagreed. So, assuming that we have work we can do without thinking about internationalization, we should do so. Otherwise we should recharter. But when we approach internationalization,we should consider all the options, their pros and cons. We should get agreement on a neutral description of what the possibilities are (even possibilities that some believe have fatal flaws) and what their pros/cons are. We're not done with hammering out the pros/cons until Nico and martin agree that we've found a neutral description of them. Options I see include: 1) locale-based handling of the current APIs. I.E. an incompatible change in the C bindings--this would need to be a new version because it's sure not GSSAPI V2. 2) New interfaces. 3) Pretend names have always been octet strings at the API level. Name types define the character set of the name. Define new UTF8 variants of the names. Define a way to deal with display name. Do something about display status. This may be an incompatible change; argue about that. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Fri Apr 28 13:51:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZX7W-000759-OA; Fri, 28 Apr 2006 13:51:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZX7V-000754-Rd for kitten@ietf.org; Fri, 28 Apr 2006 13:51:09 -0400 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZX7U-0007yj-H8 for kitten@ietf.org; Fri, 28 Apr 2006 13:51:09 -0400 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id k3SHp83i002630 for ; Fri, 28 Apr 2006 11:51:08 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id k3SHov3Q004948 for ; Fri, 28 Apr 2006 11:50:57 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k3SGfxrU013738; Fri, 28 Apr 2006 11:41:59 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k3SGfwbG013737; Fri, 28 Apr 2006 11:41:58 -0500 (CDT) Date: Fri, 28 Apr 2006 11:41:58 -0500 From: Nicolas Williams To: Sam Hartman Message-ID: <20060428164158.GP12709@binky.Central.Sun.COM> Mail-Followup-To: Sam Hartman , kitten@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: kitten@ietf.org Subject: Re: Off in the weeds X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org Well, I don't have time for this work right now, and I am not in any hurry. Please re-charter the WG to include I18N work as I now believe we have more than a clarification to make because not all implementors did the same thing. Perhaps after Montreal I'll put together a detailed proposal. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten