From kitten-bounces@lists.ietf.org Mon May 08 09:32:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd5qr-0005Jp-Q2; Mon, 08 May 2006 09:32:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd5qq-0005Jj-8i for kitten@ietf.org; Mon, 08 May 2006 09:32:40 -0400 Received: from dp.samba.org ([66.70.73.150] helo=lists.samba.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fd5qm-0000zq-1a for kitten@ietf.org; Mon, 08 May 2006 09:32:40 -0400 Received: from localhost.localdomain (localhost [127.0.0.1]) by lists.samba.org (Postfix) with ESMTP id 2DA63162AE9; Mon, 8 May 2006 13:32:31 +0000 (GMT) From: Andrew Bartlett To: Nicolas Williams 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> Date: Mon, 08 May 2006 23:32:30 +1000 Message-Id: <1147095150.30382.103.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 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="===============1859863303==" Errors-To: kitten-bounces@lists.ietf.org --===============1859863303== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-3CDoW929fZMPwe/ZxOg8" --=-3CDoW929fZMPwe/ZxOg8 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2006-04-27 at 10:23 -0500, Nicolas Williams wrote: > There are none that I can think of. >=20 > 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. >=20 > ALL just-use-8, which always amounts to: just-use-the-current-locale's- > codeset. Just as a note about Samba's place in this. Looking at interacting with Windows, I'm expecting we will slowly start on this. I suspect we will assume the libs are just-send-8 and that we will convert outside the API. =20 I hope to try and do this as 'right' as practical in Samba4, while retaining windows wire compatibility. In Samba3 (where we don't use real GSSAPI, but rather fake things up), we assume kerberos principals are UTF8 on receipt of a ticket from a client. Andrew Bartlett --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Student Network Administrator, Hawker College http://hawkerc.net --=-3CDoW929fZMPwe/ZxOg8 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQBEX0huz4A8Wyi0NrsRAiC6AJ0Yrc+CjoccM+PXcFYhJY5VHeviywCfZeNx 0sAokjycW+olXcOB5GY7KR8= =xbnW -----END PGP SIGNATURE----- --=-3CDoW929fZMPwe/ZxOg8-- --===============1859863303== 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 --===============1859863303==-- From kitten-bounces@lists.ietf.org Mon May 08 16:30:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdCNT-0007Ol-Qz; Mon, 08 May 2006 16:30:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdCNS-0007Ob-SS for kitten@ietf.org; Mon, 08 May 2006 16:30:46 -0400 Received: from nwkea-mail-5.sun.com ([192.18.42.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdCNQ-0006Zh-F5 for kitten@ietf.org; Mon, 08 May 2006 16:30:46 -0400 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by nwkea-mail-5.sun.com (8.12.10/8.12.9) with ESMTP id k48KUhaN009003 for ; Mon, 8 May 2006 13:30:43 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k48KUhTj029786 for ; Mon, 8 May 2006 14:30: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 k48KUgRm028051 for ; Mon, 8 May 2006 15:30:42 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k48KUgEa028050 for kitten@ietf.org; Mon, 8 May 2006 15:30:42 -0500 (CDT) Date: Mon, 8 May 2006 15:30:42 -0500 From: Nicolas Williams To: kitten@ietf.org Message-ID: <20060508203042.GF27799@binky.Central.Sun.COM> Mail-Followup-To: kitten@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: Subject: I18N & L10N proposal for GSS-API (v2u2/v3) 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 I propose the following solution to the I18N issue: 1) Add constants for identifying character encoding schemes with the prefix 'GSS_C_CES_' (e.g., GSS_C_CES_UTF8). The type could be INTEGER or OID, I don't care much either way. 2) Add new versions of: - GSS_Import_name() - GSS_Display_name() - GSS_Display_status() that take an additional input parameter indicating the character encoding scheme used or to be used. (And don't forget the display_as_name_type input parameter of GSS_Display_name_ext() in the naming extensions I-D.) 3) Specify two GSS_C_CES_* constants to begin with: a) GSS_C_CES_UTF8 Meaning that input human readable strings are encoded in UTF-8, and output human readable strings are to be encoded in UTF-8. b) GSS_C_CES_DEFAULT Meaning that the CES used/to be used is determined in a platform-specific manner, and typically [on POSIX/POSIX-like systems] being that which is associated with the current locale. Note that GSS_C_CES_DEFAULT, by itself, does not create special portability concerns because applications that wish to use GSS_C_CES_UTF8 on POSIX/POSIX-like platforms in non-UTF-8 locales will have to know how to do codeset conversions that they wouldn't have to know about in platforms with a single codeset/CES. That is, I18N portability concerns derive from the platforms themselves, not the GSS-API. 4) Create an IANA registry of GSS_C_CES_ values/semantics. 5) Deprecate the Latin-1-only functions and note that on some platforms they expect/use Latin-1 while on others they expect/use the CES of the current locale or equivalent local concept. 6) L10N We might as well tackle L10N and give GSS_Display_status() an input parameter indicating an RFC3066 language tag or tags to be used for localization of error messages. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon May 08 16:59:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdCot-0003T4-Vd; Mon, 08 May 2006 16:59:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdCos-0003N8-CQ for kitten@ietf.org; Mon, 08 May 2006 16:59:06 -0400 Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdCor-00009Y-0g for kitten@ietf.org; Mon, 08 May 2006 16:59:06 -0400 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id WAA23911; Mon, 8 May 2006 22:59:02 +0200 (MESZ) From: Martin Rex Message-Id: <200605082059.WAA04940@uw1048.wdf.sap.corp> To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Mon, 8 May 2006 22:59:00 +0200 (MET DST) In-Reply-To: <20060508203042.GF27799@binky.Central.Sun.COM> from "Nicolas Williams" at May 8, 6 03:30:42 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: 97adf591118a232206bdb5a27b217034 Cc: kitten@ietf.org Subject: Re: I18N & L10N proposal for GSS-API (v2u2/v3) 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 I would propose to add the following three versions instead: gss_import_name_utf8() gss_display_name_utf8() gss_display_status_utf8() because I consider it too much of a burden for gssapi mechanisms to be able to cope with every possible codepage under the sun. With the limitation to utf8, a gssapi mechanism must only know how to transform between UTF8 and the (canonical) network encoding of printables (travelling within gssapi context level tokens or being communicated out-of-band, as with the Kerberos KDC communication). The application designers should have to figure out (or worry) how many or which codepages (and conversions) are necessary to support specific environments or scenarios. I'm just trying to add support for arbitrary codepages at the gssapi at some point of our application, and it grows the code by 8-12 MBytes ... About L10N: Although I don't want to prevent anyone from going down that rathole, I will continue to use exclusively the english variant of the error message (if possible) within our application. I have been requiring that for interoperability certification with our application that the gssapi library produces meaningful error messages in english and manually review them (at least for those error-situation that gsstest tries). -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon May 08 17:02:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdCsQ-00045b-Pb; Mon, 08 May 2006 17:02:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdCsP-00045W-P4 for kitten@ietf.org; Mon, 08 May 2006 17:02:45 -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 1FdCsP-0000Dx-NR for kitten@ietf.org; Mon, 08 May 2006 17:02:45 -0400 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FdCsO-0004Ca-0q for kitten@ietf.org; Mon, 08 May 2006 17:02:45 -0400 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id k48L2gif007663 for ; Mon, 8 May 2006 14:02:43 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k48L2gKW009094 for ; Mon, 8 May 2006 15:02: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 k48L2gKH028109; Mon, 8 May 2006 16:02:42 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k48L2gHY028108; Mon, 8 May 2006 16:02:42 -0500 (CDT) Date: Mon, 8 May 2006 16:02:42 -0500 From: Nicolas Williams To: Martin Rex Message-ID: <20060508210242.GC28062@binky.Central.Sun.COM> Mail-Followup-To: Martin Rex , kitten@ietf.org References: <20060508203042.GF27799@binky.Central.Sun.COM> <200605082059.WAA04940@uw1048.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200605082059.WAA04940@uw1048.wdf.sap.corp> User-Agent: Mutt/1.5.7i X-Spam-Score: -2.3 (--) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: kitten@ietf.org Subject: Re: I18N & L10N proposal for GSS-API (v2u2/v3) 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, May 08, 2006 at 10:59:00PM +0200, Martin Rex wrote: > I would propose to add the following three versions instead: > > gss_import_name_utf8() > gss_display_name_utf8() > gss_display_status_utf8() > > because I consider it too much of a burden for gssapi mechanisms > to be able to cope with every possible codepage under the sun. Someone has to: the application or the mechanism. Perhaps we should settle that first. I vote for the burden to be on the mechanism -- there are more applications than mechanism implementations [in my world]. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon May 08 17:03:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdCsh-0004D0-UJ; Mon, 08 May 2006 17:03:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdCsg-00049Q-Au for kitten@ietf.org; Mon, 08 May 2006 17:03:02 -0400 Received: from chokecherry.srv.cs.cmu.edu ([128.2.185.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdCsf-0000E8-30 for kitten@ietf.org; Mon, 08 May 2006 17:03:02 -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 k48L2v10019438 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 8 May 2006 17:02:57 -0400 (EDT) Date: Mon, 08 May 2006 17:02:57 -0400 From: Jeffrey Hutzelman To: Nicolas Williams , kitten@ietf.org Message-ID: <5D485DA30A7A981E813E748C@sirius.fac.cs.cmu.edu> In-Reply-To: <20060508203042.GF27799@binky.Central.Sun.COM> References: <20060508203042.GF27799@binky.Central.Sun.COM> Originator-Info: login-token=Mulberry:0157cRN1EfhqszAom4GjVBpn4pSGJu64pULD+cHTc=; 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: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Subject: Re: I18N & L10N proposal for GSS-API (v2u2/v3) 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 Monday, May 08, 2006 03:30:42 PM -0500 Nicolas Williams wrote: > I propose the following solution to the I18N issue: > > 1) Add constants for identifying character encoding schemes with the > prefix 'GSS_C_CES_' (e.g., GSS_C_CES_UTF8). > > The type could be INTEGER or OID, I don't care much either way. How about an RFC2978 charset name? Or, if you really want something numberic, the MIBenum values from the same registry. > 3) Specify two GSS_C_CES_* constants to begin with: > a) GSS_C_CES_UTF8 > b) GSS_C_CES_DEFAULT > 4) Create an IANA registry of GSS_C_CES_ values/semantics. See above - we should reuse the registry that already exists for this purpose, rather than inventing our own. If we decide the functionality represented by your GSS_C_CES_DEFAULT is important, we can provide a way to indicate that is the desired behavior (for example, in C, one could pass NULL instead of a charset name) Aside from this, I agree with this proposal as it applies to GSSAPIv3. For GSSAPIv2 we are only empowered to "clarify", not to define new API elements. So I think all we can/should do is apply the same note you describe in your point 5, indicating that there are many implementations which use the charset of the current locale rather than Latin-1 as specified by GSSAPIv2. -- Jeff _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon May 08 17:29:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdDIf-0002bL-OO; Mon, 08 May 2006 17:29:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdDIf-0002bG-8N for kitten@ietf.org; Mon, 08 May 2006 17:29:53 -0400 Received: from nwkea-mail-4.sun.com ([192.18.42.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdDIe-0001rh-SP for kitten@ietf.org; Mon, 08 May 2006 17:29:53 -0400 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by nwkea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id k48LTqUm020066 for ; Mon, 8 May 2006 14:29:52 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k48LTpd1017953 for ; Mon, 8 May 2006 15:29:51 -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 k48LTpA0028143; Mon, 8 May 2006 16:29:51 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k48LTp6C028142; Mon, 8 May 2006 16:29:51 -0500 (CDT) Date: Mon, 8 May 2006 16:29:51 -0500 From: Nicolas Williams To: Martin Rex , kitten@ietf.org Message-ID: <20060508212951.GF28062@binky.Central.Sun.COM> Mail-Followup-To: Martin Rex , kitten@ietf.org References: <20060508203042.GF27799@binky.Central.Sun.COM> <200605082059.WAA04940@uw1048.wdf.sap.corp> <20060508210242.GC28062@binky.Central.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060508210242.GC28062@binky.Central.Sun.COM> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: Subject: Re: I18N & L10N proposal for GSS-API (v2u2/v3) 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, May 08, 2006 at 04:02:42PM -0500, Nicolas Williams wrote: > On Mon, May 08, 2006 at 10:59:00PM +0200, Martin Rex wrote: > > because I consider it too much of a burden for gssapi mechanisms > > to be able to cope with every possible codepage under the sun. > > Someone has to: the application or the mechanism. > > Perhaps we should settle that first. > > I vote for the burden to be on the mechanism -- there are more > applications than mechanism implementations [in my world]. Allow me to expand as to why (and then offer a concession): - Mechanisms MUST deal with stringprep and/or other conversion issues and this *cannot* be left to the application. I.e., mechanisms already MUST have some of the I18N burden placed on them. Particularly since mechanisms may have different stringprep requirements. - There are (or, darn it, should tend to be) more applications than mechanisms. I.e., placing more of the I18N burden on mechanisms means less code than placing more of the I18N burden on applications. And less code is better. The concession I may be willing to make: - REQUIRE support only for GSS_C_CES_UTF8, and REQUIRE that GSS_C_CES_DEFAULT be an alias for GSS_C_CES_UTF8 if it isn't something else. This would mean that portable GSS-APIv3 applications would have the burden of doing any charset conversions or requiring that they be run in UTF-8 locales only. However, applications intended to be portable within the POSIX world would typically be able to rely on which, for my purposes would be sufficient. Eventually most OS vendors will deprecate and stop supporting and shipping non-Unicode locales, so technically GSS_C_CES_DEFAULT would ultimately become an alias for GSS_C_CES_UTF8, and which makes GSS_C_CES_DEFAULT ultimately nothing more than a transition crutch... ...But a very good crutch. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue May 09 11:27:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdU7m-0003uO-I8; Tue, 09 May 2006 11:27:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdU7l-0003tU-8A for kitten@ietf.org; Tue, 09 May 2006 11:27:45 -0400 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdU7i-00069A-Rn for kitten@ietf.org; Tue, 09 May 2006 11:27:45 -0400 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id RAA18158; Tue, 9 May 2006 17:27:39 +0200 (MESZ) From: Martin Rex Message-Id: <200605091527.RAA27220@uw1048.wdf.sap.corp> To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Tue, 9 May 2006 17:27:38 +0200 (MET DST) In-Reply-To: <20060508210242.GC28062@binky.Central.Sun.COM> from "Nicolas Williams" at May 8, 6 04:02:42 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: 4d87d2aa806f79fed918a62e834505ca Cc: kitten@ietf.org Subject: Re: I18N & L10N proposal for GSS-API (v2u2/v3) 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 Mon, May 08, 2006 at 10:59:00PM +0200, Martin Rex wrote: > > I would propose to add the following three versions instead: > > > > gss_import_name_utf8() > > gss_display_name_utf8() > > gss_display_status_utf8() > > > > because I consider it too much of a burden for gssapi mechanisms > > to be able to cope with every possible codepage under the sun. > > Someone has to: the application or the mechanism. > > Perhaps we should settle that first. the two largest camps of existing mechanisms are: - Kerberos and Kerberos-like either completely ignoring the issue or using UTF8 (on the network) like Microsoft's implementation - SPKM or SPKM-like using X.509 certificates -- and they do have a canonical encoding (inside the certs) of mostly ASCII, ISO-8859-1 (=t61string abuse) and UTF8STRING I don't know how many gssapi mechanisms there are today that offer to convert a well-defined canonical network encoding into an arbitrary local codepage. There are likely VERY few. Claiming that an implementation supports the locale, while in fact it completely ignores the problem is not going to help us. MIT Kerberos and closely related implementations definitely ignore the issue so far, so the only interoperable codepage which they support is 7-bit US-ASCII -- not "locale"! Microsoft's Kerberos might be among those few that really support the locale on the ASCII-Variants of the SSPI-calls. > > I vote for the burden to be on the mechanism -- there are more > applications than mechanism implementations [in my world]. I'm strongly opposed to putting any burden besides iso-8859-1 and UTF8 onto the GSS-API (v3) mechanisms! Requiring a gssapi mechanism to grow by 8 MBytes in codesize in order to support a deprecated-upon-birth functionality sounds quite unreasonable to me. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue May 09 11:37:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdUHX-0005lo-5r; Tue, 09 May 2006 11:37:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdUHW-0005lj-DN for kitten@ietf.org; Tue, 09 May 2006 11:37:50 -0400 Received: from nwkea-mail-5.sun.com ([192.18.42.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdUHT-0006nE-WC for kitten@ietf.org; Tue, 09 May 2006 11:37:50 -0400 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by nwkea-mail-5.sun.com (8.12.10/8.12.9) with ESMTP id k49FblaN017927 for ; Tue, 9 May 2006 08:37:47 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k49FbkbD021645 for ; Tue, 9 May 2006 09:37:47 -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 k49FbkmE028585; Tue, 9 May 2006 10:37:46 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k49FbjgA028584; Tue, 9 May 2006 10:37:45 -0500 (CDT) Date: Tue, 9 May 2006 10:37:45 -0500 From: Nicolas Williams To: Martin Rex Message-ID: <20060509153745.GO28062@binky.Central.Sun.COM> Mail-Followup-To: Martin Rex , kitten@ietf.org References: <20060508210242.GC28062@binky.Central.Sun.COM> <200605091527.RAA27220@uw1048.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200605091527.RAA27220@uw1048.wdf.sap.corp> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: kitten@ietf.org Subject: Re: I18N & L10N proposal for GSS-API (v2u2/v3) 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, May 09, 2006 at 05:27:38PM +0200, Martin Rex wrote: > Nicolas Williams wrote: > > Someone has to: the application or the mechanism. > > > > Perhaps we should settle that first. > > the two largest camps of existing mechanisms are: > > - Kerberos and Kerberos-like either completely ignoring the issue > or using UTF8 (on the network) like Microsoft's implementation > > - SPKM or SPKM-like using X.509 certificates -- and they do have > a canonical encoding (inside the certs) of mostly ASCII, > ISO-8859-1 (=t61string abuse) and UTF8STRING > > I don't know how many gssapi mechanisms there are today that > offer to convert a well-defined canonical network encoding > into an arbitrary local codepage. There are likely VERY few. > > Claiming that an implementation supports the locale, while in > fact it completely ignores the problem is not going to help us. I didn't make that claim. > > I vote for the burden to be on the mechanism -- there are more > > applications than mechanism implementations [in my world]. > > I'm strongly opposed to putting any burden besides > iso-8859-1 and UTF8 onto the GSS-API (v3) mechanisms! Did you see my follow-up to myself? Wherein I offer a concession in this regard that should make you happy? > Requiring a gssapi mechanism to grow by 8 MBytes in codesize > in order to support a deprecated-upon-birth functionality sounds > quite unreasonable to me. Huh? Dynamic linking and all that. But anyways, in my follow-up to the mail you were replying to I offer to make only GSS_C_CES_UTF8 REQUIRED, which means that you could have a compliant mechanism implementation that caters only for UTF-8 and does no conversions. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue May 09 13:16:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdVp9-0005s9-IK; Tue, 09 May 2006 13:16:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdVp8-0005s4-2o for kitten@ietf.org; Tue, 09 May 2006 13:16:38 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdVp7-00038U-RJ for kitten@ietf.org; Tue, 09 May 2006 13:16:38 -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 serrano.cc.columbia.edu (8.13.6/8.13.6) with ESMTP id k49HGaGG003744 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 9 May 2006 13:16:37 -0400 (EDT) Message-ID: <4460CE6A.2090500@columbia.edu> Date: Tue, 09 May 2006 13:16:26 -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: <20060508203042.GF27799@binky.Central.Sun.COM> <200605082059.WAA04940@uw1048.wdf.sap.corp> <20060508210242.GC28062@binky.Central.Sun.COM> <20060508212951.GF28062@binky.Central.Sun.COM> In-Reply-To: <20060508212951.GF28062@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.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: Subject: Re: I18N & L10N proposal for GSS-API (v2u2/v3) 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="===============1090409381==" Errors-To: kitten-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============1090409381== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000007060000080000080908" This is a cryptographically signed message in MIME format. --------------ms000007060000080000080908 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Nicolas Williams wrote: > The concession I may be willing to make: > > - REQUIRE support only for GSS_C_CES_UTF8, and REQUIRE that > GSS_C_CES_DEFAULT be an alias for GSS_C_CES_UTF8 if it isn't > something else. > > This would mean that portable GSS-APIv3 applications would have the > burden of doing any charset conversions or requiring that they be run > in UTF-8 locales only. > > However, applications intended to be portable within the POSIX world > would typically be able to rely on which, for my purposes would be > sufficient. > > > Eventually most OS vendors will deprecate and stop supporting and > shipping non-Unicode locales, so technically GSS_C_CES_DEFAULT would > ultimately become an alias for GSS_C_CES_UTF8, and which makes > GSS_C_CES_DEFAULT ultimately nothing more than a transition crutch... > > ...But a very good crutch. > > Nico >From a practical perspective I don't see this proposal as being much different than adding the "_utf8" versions that Martin is suggesting and using the existing versions as they are used today. Applications will eventually migrate to the _utf8 versions and eventually we will deprecate the old versions. I do believe that applications should speak to portable APIs in a portable character set. I would like to think that mechanism implementations are more cross-platform than applications. By that I mean that a mechanism should not have to rely on platform specific functions in order to accomplish their job. That a GSS-KRB5 mechanism written for Solaris, would work just as well on Linux and MacOS X. The set of locales that are implemented on an operating system is specific to the OS. I do not believe that GSS mechanism authors should be required to support the superset of all locales and write platform specific code to enable character-set translation. Mechanisms will have to utilize character-set manipulation routines in order to implement stringprep. However, those routines are going to be portable and are not functions that would be provided by the OS in any case. Applications on the other hand already have to be locale aware and the authors need to perform character set manipulation already when dealing with a mixture of UCS2, UTF8, and non-Unicode representations. I do not believe that strongly encouraging the use of UTF8 for GSS is a significant additional burden and by doing so we will improve security by reducing the potential for character-set confusion to be used to attack applications which are unaware of the input character-set of the peer. Jeffrey Altman (speaking as an individual) burden. However, it would --------------ms000007060000080000080908 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 DxcNMDYwNTA5MTcxNjI2WjAjBgkqhkiG9w0BCQQxFgQUCUxc8S4npZJ5tdYPsyRL+c58XSQw UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw7NrDB6BgsqhkiG9w0B CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AgMOzawwDQYJKoZIhvcNAQEBBQAEggEARbQkw8Lbt0IHh+GLP9usxRwx2Vn69SIzrmzFXvD9 PPNbgzFs8I8q4M+8gvEliHaGBgK6fvYPE2NxhUqoZCky+kdXXFrcaTOftsd9lhnWRcGl5dcB AXHSZLpAJEPQsiPxxHTyUBQG9SZ3/wr6extC9LCTCOH0aTTDxx6AIrB5qSU/MerUMxL01eHO z+NL5xVcvxk9RgmW1TTo3b7t1iFNXVbVnWF1XhFJxqFIraplZ+P+YRa0OJByWNIFKWtia2Rr W9/sC70+Lsntf1zd5wS7NZwVGttaK64TapCriwXYRXAmheLsqSp/tJxAL/nCWPmXjFg4IMJR +afKwFQ6AdrekwAAAAAAAA== --------------ms000007060000080000080908-- --===============1090409381== 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 --===============1090409381==-- From kitten-bounces@lists.ietf.org Tue May 09 13:27:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdVzu-0003jj-02; Tue, 09 May 2006 13:27:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdVzt-0003je-5B for kitten@ietf.org; Tue, 09 May 2006 13:27:45 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdVzr-0003Ue-UA for kitten@ietf.org; Tue, 09 May 2006 13:27:45 -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 k49HRcKZ006303 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 9 May 2006 13:27:43 -0400 (EDT) Message-ID: <4460D101.5060603@columbia.edu> Date: Tue, 09 May 2006 13:27:29 -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: <20060508210242.GC28062@binky.Central.Sun.COM> <200605091527.RAA27220@uw1048.wdf.sap.corp> <20060509153745.GO28062@binky.Central.Sun.COM> In-Reply-To: <20060509153745.GO28062@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: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: Subject: Re: I18N & L10N proposal for GSS-API (v2u2/v3) 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="===============1114601805==" Errors-To: kitten-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============1114601805== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030107060108030103010300" This is a cryptographically signed message in MIME format. --------------ms030107060108030103010300 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Nicolas Williams wrote: > But anyways, in my follow-up to the mail you were replying to I offer to > make only GSS_C_CES_UTF8 REQUIRED, which means that you could have a > compliant mechanism implementation that caters only for UTF-8 and does > no conversions. > > Nico Nico: All I see this resulting in is a new negotiation problem. The application and the mechanism now have to negotiate over the common set of character-sets that both support. If we don't support negotiation and a mechanism is passed GSS_C_CES_KLINGON what is it supposed to do? All it can do is return an error indicating unsupported character-set. At that point the application will have to perform translation to UTF8. While the concept of selectable character sets has the potential to save a few hours of application developer programming time, I don't see it providing any real benefits. All of the major OSs already provide application developers with the functions to convert from locale to UTF8 and back. Requiring that application developers make such calls or be UTF8 based prior to using GSSv3 is truly not a big deal in my mind. Jeffrey Altman (speaking as an individual) --------------ms030107060108030103010300 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 DxcNMDYwNTA5MTcyNzI5WjAjBgkqhkiG9w0BCQQxFgQU+E5mwWPTNTdYByHx1R1GW55hFPkw UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw7NrDB6BgsqhkiG9w0B CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AgMOzawwDQYJKoZIhvcNAQEBBQAEggEANaqC3GITdEzWIHsZ9CSmgXj3gsvLPM3FzugCUSG+ KOVj0NKRxvV9ZpBnja2RFbIVkaH3e0eDcpKntwzPqjseFZJ5CcQU14hgfX//t3GRRN8SlE7x m8IWEFMj0igp7DyPcKjLohq9iCWuuLaqxrqRqN3DAqjr/vCaKwy6oTqCfVKdVYY3s9RpP+qF q0e0RFq4qw2IuMzFZ4vP4iIcyROUucFz9RVAy1RPh326dS3RZJ9q36o/Jw6tGvsnXhdsvmjt 7m0QchVhWjP5M7QuNrw7NAf5imCEu8S9W30vxpKgDVZ53gNZZw4oUGr3rz1RD+YxMLuxFnul U43mQYm1aj0fYwAAAAAAAA== --------------ms030107060108030103010300-- --===============1114601805== 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 --===============1114601805==-- From kitten-bounces@lists.ietf.org Tue May 09 13:36:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdW8j-00008P-Ac; Tue, 09 May 2006 13:36:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdW8i-00008A-Fu for kitten@ietf.org; Tue, 09 May 2006 13:36:52 -0400 Received: from li4-142.members.linode.com ([66.220.1.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdW8g-0003sy-7D for kitten@ietf.org; Tue, 09 May 2006 13:36:52 -0400 Received: from quark.foo.net (c-69-142-196-170.hsd1.nj.comcast.net [69.142.196.170]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by li4-142.members.linode.com (Postfix) with ESMTP id E4A9A42B69; Tue, 9 May 2006 13:36:42 -0400 (EDT) Date: Tue, 9 May 2006 13:34:26 -0400 From: Michael B Allen To: Nicolas Williams Message-Id: <20060509133426.45adb8d9.mba2000@ioplex.com> In-Reply-To: <20060508203042.GF27799@binky.Central.Sun.COM> References: <20060508203042.GF27799@binky.Central.Sun.COM> X-Mailer: Sylpheed version 1.0.6 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.6 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: kitten@ietf.org Subject: Re: I18N & L10N proposal for GSS-API (v2u2/v3) 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 I'm a newbie here so don't weight my input much but I've done a lot of i18n conscience programming so here's a data point for your stats. Text in interprocess messages (e.g. network protocol messages) should be UTF-8. If it has been preestablished that text is of another encoding (e.g. Latin1) then that should be changed even if it means compromising backwards compatibility. Programming interfaces should use the encoding defined by the current locale. Virtually all APIs are written this way regardless of what the standards say. Mike _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue May 09 14:52:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdXJk-0001d7-Bx; Tue, 09 May 2006 14:52:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdXJi-0001d2-Af for kitten@ietf.org; Tue, 09 May 2006 14:52:18 -0400 Received: from nwkea-mail-4.sun.com ([192.18.42.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdXJg-0007Mh-T1 for kitten@ietf.org; Tue, 09 May 2006 14:52:18 -0400 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by nwkea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id k49IqFUm013422 for ; Tue, 9 May 2006 11:52:15 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k49IqEuk020992 for ; Tue, 9 May 2006 12:52:15 -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 k49IqEjI028701; Tue, 9 May 2006 13:52:14 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k49IqDL3028700; Tue, 9 May 2006 13:52:13 -0500 (CDT) Date: Tue, 9 May 2006 13:52:13 -0500 From: Nicolas Williams To: Jeffrey Altman Message-ID: <20060509185213.GC28647@binky.Central.Sun.COM> Mail-Followup-To: Jeffrey Altman , kitten@ietf.org References: <20060508203042.GF27799@binky.Central.Sun.COM> <200605082059.WAA04940@uw1048.wdf.sap.corp> <20060508210242.GC28062@binky.Central.Sun.COM> <20060508212951.GF28062@binky.Central.Sun.COM> <4460CE6A.2090500@columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4460CE6A.2090500@columbia.edu> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: kitten@ietf.org Subject: Re: I18N & L10N proposal for GSS-API (v2u2/v3) 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, May 09, 2006 at 01:16:26PM -0400, Jeffrey Altman wrote: > I do believe that applications should speak to portable APIs in a > portable character set. I would like to think that mechanism > implementations are more cross-platform than applications. By that I > mean that a mechanism should not have to rely on platform specific > functions in order to accomplish their job. That a GSS-KRB5 mechanism > written for Solaris, would work just as well on Linux and MacOS X. Stop right there. The GSS-API is supposed to help develop portable applications, not portable mechanisms. I see nothing, in fact, about portable mechanisms in RFC2743. Also, clearly GSS-API applications typically have to use OS facilities that can be and are platform-specific, because, for example, GSS-API applications are intended to be _networked_ applications, and details of socket/XTI/TLI/other networking APIs vary. So though the GSS-API promotes application portability, there's no way that it can guarantee this. For example, how do you write a portable server application that properly localizes messages for its remote users? Whether the application uses the GSS-API, SASL or no security framework at all it still has to deal with this problem and nothing in the GSS-API can help it as the GSS-API is NOT a general operating system interface -- it's an interface to security mechanisms. I'd really rather not rathole on this though. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue May 09 15:00:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdXRW-0002KY-BH; Tue, 09 May 2006 15:00:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdXRT-0002Jo-OB for kitten@ietf.org; Tue, 09 May 2006 15:00:19 -0400 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdXRQ-0007jS-CL for kitten@ietf.org; Tue, 09 May 2006 15:00:19 -0400 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id k49J0FIH013895 for ; Tue, 9 May 2006 13:00:15 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k49J0FwU024548 for ; Tue, 9 May 2006 13:00:15 -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 k49J0FQG028710; Tue, 9 May 2006 14:00:15 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k49J0FLG028709; Tue, 9 May 2006 14:00:15 -0500 (CDT) Date: Tue, 9 May 2006 14:00:14 -0500 From: Nicolas Williams To: Jeffrey Altman Message-ID: <20060509190014.GD28647@binky.Central.Sun.COM> Mail-Followup-To: Jeffrey Altman , kitten@ietf.org References: <20060508210242.GC28062@binky.Central.Sun.COM> <200605091527.RAA27220@uw1048.wdf.sap.corp> <20060509153745.GO28062@binky.Central.Sun.COM> <4460D101.5060603@columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4460D101.5060603@columbia.edu> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: kitten@ietf.org Subject: Re: I18N & L10N proposal for GSS-API (v2u2/v3) 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, May 09, 2006 at 01:27:29PM -0400, Jeffrey Altman wrote: > All I see this resulting in is a new negotiation problem. The > application and the mechanism now have to negotiate over the common > set of character-sets that both support. > > If we don't support negotiation and a mechanism is passed > GSS_C_CES_KLINGON what is it supposed to do? All it can do is > return an error indicating unsupported character-set. Correct. And when using GSS_C_CES_DEFAULT, if the default wouldn't be UTF-8 and it isn't supported, then an error would have to be returned as well. > At that point > the application will have to perform translation to UTF8. There will be no such applications, but if there were they would fail. Applications that use GSS_C_CES_DEFAULT should be prepared to fail and tell users to use a UTF-8 locale. Applications that use GSS_C_CES_UTF8 should just work (provided the mechanisms work too). Applications that use any other CES should be prepared to either perform their own codeset conversions or fail and, if desired, offer users an alternative. > While the > concept of selectable character sets has the potential to save a few > hours of application developer programming time, I don't see it > providing any real benefits. All of the major OSs already provide > application developers with the functions to convert from locale to > UTF8 and back. Requiring that application developers make such calls > or be UTF8 based prior to using GSSv3 is truly not a big deal in my > mind. On platforms where the locale determines the codeset used in many/most APIs having to modify apps to know how to do codeset conversions for odd APIs like the GSS-API would be at the very least obnoxious. My bottom-line: I want a compliant way to do what our applications do and I don't want to have to modify our applications to perform codeset conversions. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue May 09 15:05:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdXWC-0007Yx-57; Tue, 09 May 2006 15:05:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdXWB-0007Wz-4D for kitten@ietf.org; Tue, 09 May 2006 15:05:11 -0400 Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdXW8-0007wQ-L7 for kitten@ietf.org; Tue, 09 May 2006 15:05:11 -0400 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id VAA25959; Tue, 9 May 2006 21:05:00 +0200 (MESZ) From: Martin Rex Message-Id: <200605091905.VAA01740@uw1048.wdf.sap.corp> To: mba2000@ioplex.com (Michael B Allen) Date: Tue, 9 May 2006 21:05:00 +0200 (MET DST) In-Reply-To: <20060509133426.45adb8d9.mba2000@ioplex.com> from "Michael B Allen" at May 9, 6 01:34:26 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: 6d95a152022472c7d6cdf886a0424dc6 Cc: kitten@ietf.org, Nicolas.Williams@sun.com Subject: Re: I18N & L10N proposal for GSS-API (v2u2/v3) 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 Michael B Allen wrote: > > I'm a newbie here so don't weight my input much but I've done a lot of > i18n conscience programming so here's a data point for your stats. > > Text in interprocess messages (e.g. network protocol messages) should > be UTF-8. If it has been preestablished that text is of another encoding > (e.g. Latin1) then that should be changed even if it means compromising > backwards compatibility. > > Programming interfaces should use the encoding defined by the current > locale. Virtually all APIs are written this way regardless of what the > standards say. I believe this to be a major misconception! Few, if any, current APIs *really* support locale. Quite a lot of code on Posix/Unix platforms entirely ignores it -- which is completely different. The only APIs that seem to support locale today are those in the base language standard (ctype family in the programming language C). When I started working with Unix machines on a daily basis in 1993, I was supplied with a HP PARISC workstation. When working on the graphical console under X-Windows, the default "terminal emulator" provided by the OS vendor was the "hpterm" and the default fonts were the "hp roman" fonts using some codepage that was definitely not iso-8859-1 -- but the default tty attributes were 7-bit with parity enabled, so this wasn't the only problem... My language (German) contains a few non-ASCII characters, and sometimes I was reading plain text messages with such characters in iso-8859-1, so I adjusted my settings to use the standard X11 instead. (I also fixed the tty settings, shell capabilities and switched to using standard x11 xterms across all of the Unix platforms). Anyway -- because none of the software was locale-aware (i.e. did NOT seperate internal/network/filesystem encoding from visualization and user i/o encoding) it did matter significantly what font one selected! When I wrote my first program for Microsoft Windows in 1993, it was a 3270-terminal emulation for accessing IBM Mainframes from a Windows NT based PC (in order to replace several hundred green-screens). I was faced with the codepage conversion issue from the beginning for this program due to the fact that Mainframes use some un-identified EBCDIC codepage and (our) Windows machines used an ASCII-based single-byte codepage from the ISO-Latin series. When adding the possibility for the user to select an arbitrary font, I had to take into account which codepage/encoding was used by the font in order to visualize the characters correctly. On a Windows system, Fixedsys is an "ANSI" font, whereas "Terminal" (also known as Raster font in a CMD.EXE) is encoded with DOS/OEM. The encoding of the font for visualization is entirely seperate from the codepage that the application uses internally (here the IBM mainframe in the backend). Actually, the Mainframe backend was equally ignorant about codepages as most applications are (and were at that times), and it was entirely dependent on the context (or country) what codepage the people wanted to use. So in addition to the font selection, I added the capability to select a particular EBCDIC codepage in order to communicate with the IBM Mainframe. From what I remember there are 13 western european codepages that contain the exact same set of characters from ISO-8859-1, with about a dozen character posistions garbled (there was some ancient economical reason behind this garbling, but in 1993 it appeared like pure nonsense). Anyway -- we had Germans in the HR department needing Umlauts, we had developers that needed brackets and braces for programming in C and we had some users in spain, scandinavia and eastern european countries which all wanted support for their specific codepages for their application. Why am I telling such a long story: Well, I don't think one can save the application level (which implements the presentation layer) from doing locale-specific conversions (e.g. to match font encodings). So I think there should be a resonable and easy to implement canonical encoding at the API level, and all of the localization and codepage conversion issues should be handled by the application layers -- because they will have to do it anyway if the application wants to offer localization. There are areas/scenarios (set-top-boxes, embedded like WLAN-Routers or palmtops/mobile phones) with serious restrictions on size/space of the code and there the application must decided how much localization is necessary and how it is implemented. If I start notepad on my current WinXPsp2 machine and type some Umlauts, then change the font from its default (lucida console 10pt) to Terminal 9pt then I no longer see umlauts, I see mathematical symbols instead. If I continue typing umlauts with Terminal font selected, then I continue to get mathematical symbols, not umlauts. This might appear consistent -- but it clearly shows that "notepad.exe" on Windows XP does *NOT* support locale, instead it uses the "just-use-8" approach and ignores the codepage (of both, the text it processes and the encoding of the chosen font). Btw. Microsoft Visual Studio 2005 text editor behaves just the same, as does vi on Unix (and probably a lot of other text editors on Unix). -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue May 09 15:22:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdXmr-0006BH-VP; Tue, 09 May 2006 15:22:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdXmr-000695-68 for kitten@ietf.org; Tue, 09 May 2006 15:22:25 -0400 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdXmp-0008QE-Tl for kitten@ietf.org; Tue, 09 May 2006 15:22:25 -0400 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id k49JMNSX024253 for ; Tue, 9 May 2006 13:22:23 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k49JMN1o005712 for ; Tue, 9 May 2006 13:22:23 -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 k49JMM7O028785; Tue, 9 May 2006 14:22:22 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k49JML9X028784; Tue, 9 May 2006 14:22:21 -0500 (CDT) Date: Tue, 9 May 2006 14:22:21 -0500 From: Nicolas Williams To: Martin Rex Message-ID: <20060509192221.GG28647@binky.Central.Sun.COM> Mail-Followup-To: Martin Rex , Michael B Allen , kitten@ietf.org References: <20060509133426.45adb8d9.mba2000@ioplex.com> <200605091905.VAA01740@uw1048.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200605091905.VAA01740@uw1048.wdf.sap.corp> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: kitten@ietf.org Subject: Re: I18N & L10N proposal for GSS-API (v2u2/v3) 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, 1993 was a long time ago, and some Unix vendors (see my e-mail address for one example) care about backwards compatibility, so that as we internationalize the OS we do look to leverage a current locale's codeset assumption where we can (e.g., by deprecating non-UTF-8 locales, say -- which Sun has not yet done, BTW) and we tend to prefer UTF-8, all because it leads to less code change, not only for our code bases but also for third parties'. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue May 09 16:03:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdYQH-0002RU-Fz; Tue, 09 May 2006 16:03:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdYQG-0002RP-DW for kitten@ietf.org; Tue, 09 May 2006 16:03:08 -0400 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdYQF-0002DK-12 for kitten@ietf.org; Tue, 09 May 2006 16:03:08 -0400 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id WAA20613; Tue, 9 May 2006 22:03:01 +0200 (MESZ) From: Martin Rex Message-Id: <200605092003.WAA03020@uw1048.wdf.sap.corp> To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Tue, 9 May 2006 22:03:00 +0200 (MET DST) In-Reply-To: <20060509192221.GG28647@binky.Central.Sun.COM> from "Nicolas Williams" at May 9, 6 02:22:21 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: 0ddefe323dd869ab027dbfff7eff0465 Cc: kitten@ietf.org Subject: Re: I18N & L10N proposal for GSS-API (v2u2/v3) 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: > > Martin, 1993 was a long time ago, and some Unix vendors (see my e-mail > address for one example) care about backwards compatibility, so that as > we internationalize the OS we do look to leverage a current locale's > codeset assumption where we can (e.g., by deprecating non-UTF-8 locales, > say -- which Sun has not yet done, BTW) and we tend to prefer UTF-8, all > because it leads to less code change, not only for our code bases but > also for third parties'. Please take into account that there is a significant lag in what "new features" vendors ship with their most current release of their software compared to what other software vendors use to build their software. E.g. we use Solaris 5.8 (sparc) for build that release of our software that is most widely used, and we're likely going to build that particular release on Solaris 5.8 until at least 2010 (even though customers are allowed to install/use the software on solaris 5.9 and soon 5.10). Similarly, there is code that I ship "release-independent", which must work on solaris unchanged down to SunOS 5.6 and on Windows down to Win95/NT4 (everything else would significantly complicate software logistics). That includes our OEM PKI toolkit and the Windows-specific gsskrb5.dll wrapper for Microsoft's Kerberos SSP (gsskrb5.dll shares most code with its brother gssntlm.dll -- and that can be used on Win95/NT4 as well). Contrast this to the DLL-nightmare that Microsoft has started with their MSVCRT-family of DLLs (the C Runtime library), i.e. do a "dir %SystemRoot%\msvcrt*.dll" on a windows machine that has seen all all of the compilers since VStudio98 and a decent set of apps/helpers installed... Incompatible changes are evil. Having software logistics in place to hide frequent incompatible changes from your customers / end users doesn't make it less evil. If we add only the three utf8-capable API calls to GSS-API v3, then (a) more gssapi mechanism implementors are likely to adopt it because they're "fairly" easy to implement, and (b) application programmers are likely to use them when they find them because they will get exactly the same functionality from every gssapi implementation that has these calls. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue May 09 16:23:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdYk9-0002Ap-78; Tue, 09 May 2006 16:23:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdYk8-0002Ak-3Q for kitten@ietf.org; Tue, 09 May 2006 16:23:40 -0400 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdYk7-0003o2-Om for kitten@ietf.org; Tue, 09 May 2006 16:23:40 -0400 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id k49KNdIH006114 for ; Tue, 9 May 2006 14:23:39 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k49KNcWm002508 for ; Tue, 9 May 2006 14:23:38 -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 k49KNcib028857; Tue, 9 May 2006 15:23:38 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k49KNcCb028856; Tue, 9 May 2006 15:23:38 -0500 (CDT) Date: Tue, 9 May 2006 15:23:38 -0500 From: Nicolas Williams To: Martin Rex Message-ID: <20060509202338.GM28647@binky.Central.Sun.COM> Mail-Followup-To: Martin Rex , mba2000@ioplex.com, kitten@ietf.org References: <20060509192221.GG28647@binky.Central.Sun.COM> <200605092003.WAA03020@uw1048.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200605092003.WAA03020@uw1048.wdf.sap.corp> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: kitten@ietf.org Subject: Re: I18N & L10N proposal for GSS-API (v2u2/v3) 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, May 09, 2006 at 10:03:00PM +0200, Martin Rex wrote: > Nicolas Williams wrote: > > > > Martin, 1993 was a long time ago, and some Unix vendors (see my e-mail > > address for one example) care about backwards compatibility, so that as > > we internationalize the OS we do look to leverage a current locale's > > codeset assumption where we can (e.g., by deprecating non-UTF-8 locales, > > say -- which Sun has not yet done, BTW) and we tend to prefer UTF-8, all > > because it leads to less code change, not only for our code bases but > > also for third parties'. > > Please take into account that there is a significant lag in what > "new features" vendors ship with their most current release of their > software compared to what other software vendors use to build their > software. I am aware. If, as you say, you ship applications built for Solaris and you use Solaris' libgss then you'll have to accept it's current expectation that the codeset used is that which is associated with the current locale. > E.g. we use Solaris 5.8 (sparc) for build that release of our > software that is most widely used, and we're likely going to build > that particular release on Solaris 5.8 until at least 2010 > (even though customers are allowed to install/use the software > on solaris 5.9 and soon 5.10). > > Similarly, there is code that I ship "release-independent", > which must work on solaris unchanged down to SunOS 5.6 and on > Windows down to Win95/NT4 (everything else would significantly > complicate software logistics). That includes our OEM PKI toolkit > and the Windows-specific gsskrb5.dll wrapper for Microsoft's > Kerberos SSP (gsskrb5.dll shares most code with its brother > gssntlm.dll -- and that can be used on Win95/NT4 as well). At some point third parties have to drop support for OS releases that are no longer supported by the OS vendors. Sun does not support any release of Solaris earlier than Solaris 8, Microsoft does not support NT4, and so on. > Contrast this to the DLL-nightmare that Microsoft has started > with their MSVCRT-family of DLLs (the C Runtime library), > i.e. do a "dir %SystemRoot%\msvcrt*.dll" on a windows machine > that has seen all all of the compilers since VStudio98 and > a decent set of apps/helpers installed... Huh? (That's rhetorical.) > Incompatible changes are evil. Yes, at least without sufficient warning. Note that going from "non-ASCII in char * argument to this function has undefined results" to "this char * argument to this function expects strings in the CES of the current local" is not an incompatible change unless the "undefined results" in the original were reliable and came to be relied upon. > Having software logistics in place to hide frequent incompatible > changes from your customers / end users doesn't make it less evil. If you'd like to make a complaint about Solaris in this regard please be specific, and use an OpenSolaris discussion list, not an IETF list. > If we add only the three utf8-capable API calls to GSS-API v3, > then (a) more gssapi mechanism implementors are likely to adopt > it because they're "fairly" easy to implement, and (b) > application programmers are likely to use them when they find > them because they will get exactly the same functionality > from every gssapi implementation that has these calls. This is a good argument, but doesn't win me over completely because as I see it GSS-API app developers on POSIX/POSIX-like systems will likely write wrappers around these functions that perform any necessary codeset conversions from/to the current locale's codeset and UTF-8 as required in your proposed gss_*_utf8 functions. I.e., let us give such developers what they want already. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue May 09 17:25:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdZiA-0006Rq-5c; Tue, 09 May 2006 17:25:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdZi9-0006R3-44 for kitten@ietf.org; Tue, 09 May 2006 17:25:41 -0400 Received: from li4-142.members.linode.com ([66.220.1.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdZi6-0007Kh-R3 for kitten@ietf.org; Tue, 09 May 2006 17:25:41 -0400 Received: from quark.foo.net (c-69-142-196-170.hsd1.nj.comcast.net [69.142.196.170]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by li4-142.members.linode.com (Postfix) with ESMTP id 6C50042B69; Tue, 9 May 2006 17:25:33 -0400 (EDT) Date: Tue, 9 May 2006 17:23:17 -0400 From: Michael B Allen To: martin.rex@sap.com Message-Id: <20060509172317.3d7915e7.mba2000@ioplex.com> In-Reply-To: <200605091905.VAA01740@uw1048.wdf.sap.corp> References: <20060509133426.45adb8d9.mba2000@ioplex.com> <200605091905.VAA01740@uw1048.wdf.sap.corp> X-Mailer: Sylpheed version 1.0.6 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.6 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: kitten@ietf.org, Nicolas.Williams@sun.com Subject: Re: I18N & L10N proposal for GSS-API (v2u2/v3) 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, 9 May 2006 21:05:00 +0200 (MET DST) Martin Rex wrote: > Michael B Allen wrote: > > > > I'm a newbie here so don't weight my input much but I've done a lot of > > i18n conscience programming so here's a data point for your stats. > > > > Text in interprocess messages (e.g. network protocol messages) should > > be UTF-8. If it has been preestablished that text is of another encoding > > (e.g. Latin1) then that should be changed even if it means compromising > > backwards compatibility. > > > > Programming interfaces should use the encoding defined by the current > > locale. Virtually all APIs are written this way regardless of what the > > standards say. > > I believe this to be a major misconception! > > Few, if any, current APIs *really* support locale. Quite a lot of code on > Posix/Unix platforms entirely ignores it -- which is completely different. True, but those programs are just slightly broken. To fix them to *really* support locales is a matter of: 1) fixing any code that needs to understand variable width encoding (e.g. caseless comparison of UTF-8 strings) and 2) calling setlocale(LC_CTYPE, "") in main Newer, robust libraries use this convention because it supports the desired full Unicode UTF-8 locale as well as folks still running Latin1 on their PARISC from 1993. As long everyone sticks to the plan things seamlessly cascade together and conversion only occurs when interprocess communication is necessary (e.g. network protocols and files) or when interacting with code that does not follow the convention. Mike _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue May 09 17:43:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdZzY-0006Sj-R3; Tue, 09 May 2006 17:43:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdZzY-0006Se-GJ for kitten@ietf.org; Tue, 09 May 2006 17:43:40 -0400 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdZzX-00087M-4G for kitten@ietf.org; Tue, 09 May 2006 17:43:40 -0400 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id XAA03025; Tue, 9 May 2006 23:43:35 +0200 (MESZ) From: Martin Rex Message-Id: <200605092143.XAA05375@uw1048.wdf.sap.corp> To: mba2000@ioplex.com (Michael B Allen) Date: Tue, 9 May 2006 23:43:34 +0200 (MET DST) In-Reply-To: <20060509172317.3d7915e7.mba2000@ioplex.com> from "Michael B Allen" at May 9, 6 05:23:17 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: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: kitten@ietf.org, Nicolas.Williams@sun.com Subject: Re: I18N & L10N proposal for GSS-API (v2u2/v3) 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 Michael B Allen wrote: > Martin Rex wrote: > > > Michael B Allen wrote: > > > > > > Programming interfaces should use the encoding defined by the current > > > locale. Virtually all APIs are written this way regardless of what the > > > standards say. > > > > I believe this to be a major misconception! > > > > Few, if any, current APIs *really* support locale. Quite a lot of code on > > Posix/Unix platforms entirely ignores it -- which is completely different. > > True, but those programs are just slightly broken. To fix them to *really* > support locales is a matter of: > > 1) fixing any code that needs to understand variable width encoding (e.g. > caseless comparison of UTF-8 strings) and > 2) calling setlocale(LC_CTYPE, "") in main I mentioned it before: traditional multi-byte locales provide real pitfalls for code that is not locale-aware. The problem is if the existing code does some amount of parsing on the string and looks for particular occurrances of certain ASCII characters in strings, not knowing whether it is dealing with a single-byte codepage or a traditional multibyte codepage, because the trail byte of such a multibyte codepage can be confused with a regular ASCII character. UTF-8 is safe because with UTF-8, every octet of a multi-byte character as the highest bit set. MIT Kerberos 5 does definitely have such a problem with the realm seperator "@" character -- and every GSS-API mechanism that implement the hostbased service nametype and is locale-ignorant will also have this problem with this nametype. And we still don't know how and where to handle IDN (internationalized domain names) into punycode conversion for hostbased service names and within kerberos service principals... -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue May 09 17:55:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdaBE-0003Db-A8; Tue, 09 May 2006 17:55:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdaBC-0003DV-CP for kitten@ietf.org; Tue, 09 May 2006 17:55:42 -0400 Received: from nwkea-mail-4.sun.com ([192.18.42.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdaB9-0008So-Ng for kitten@ietf.org; Tue, 09 May 2006 17:55:42 -0400 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by nwkea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id k49LtcUm002229 for ; Tue, 9 May 2006 14:55:39 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k49LtcJV012604 for ; Tue, 9 May 2006 15:55:38 -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 k49LtctX028966; Tue, 9 May 2006 16:55:38 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k49Ltbxd028965; Tue, 9 May 2006 16:55:37 -0500 (CDT) Date: Tue, 9 May 2006 16:55:37 -0500 From: Nicolas Williams To: Martin Rex Message-ID: <20060509215537.GZ28647@binky.Central.Sun.COM> Mail-Followup-To: Martin Rex , Michael B Allen , kitten@ietf.org References: <20060509172317.3d7915e7.mba2000@ioplex.com> <200605092143.XAA05375@uw1048.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200605092143.XAA05375@uw1048.wdf.sap.corp> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: kitten@ietf.org Subject: Re: I18N & L10N proposal for GSS-API (v2u2/v3) 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, May 09, 2006 at 11:43:34PM +0200, Martin Rex wrote: > And we still don't know how and where to handle IDN (internationalized > domain names) into punycode conversion for hostbased service names > and within kerberos service principals... There is plenty of material in the IETF KRB WG mailing list archive and proceedings. I would say that we *do* know what to do about the intersection of IDN and Kerberos V, and punycode is not involved. (What matters is the stringprep profiles, not the particular encoding of Unicode.) I don't want us discussing Kerberos V I18N, but I do want us to agree that that that a mechanism-specific issue, not a matter for Kerberos V or RFC4121 applications -- if we can't reach consensus on this then we have a problem. This isn't to say that GSS-API apps shouldn't use UTF-8 natively, mind you, but that there's no inherent link between what a mechanism does on the wire and what the API requires of applications as long as the API doesn't force one to use a non-Unicode CES. Even if we adopt the gss_*_utf8() proposal we'd still not specify stringprep profiles, or even just normalization forms for gss_*_utf8() UTF-8 inputs/outputs, but GSS mechanisms that use Unicode on the wire MUST specify stringprep profiles. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue May 09 18:17:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdaVn-0000FO-RA; Tue, 09 May 2006 18:16:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdaVm-0000F5-Ay for kitten@ietf.org; Tue, 09 May 2006 18:16:58 -0400 Received: from li4-142.members.linode.com ([66.220.1.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdaVl-0000kx-2E for kitten@ietf.org; Tue, 09 May 2006 18:16:58 -0400 Received: from quark.foo.net (c-69-142-196-170.hsd1.nj.comcast.net [69.142.196.170]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by li4-142.members.linode.com (Postfix) with ESMTP id E3FE142C4A; Tue, 9 May 2006 18:16:55 -0400 (EDT) Date: Tue, 9 May 2006 18:14:39 -0400 From: Michael B Allen To: martin.rex@sap.com Message-Id: <20060509181439.4961fc85.mba2000@ioplex.com> In-Reply-To: <200605092143.XAA05375@uw1048.wdf.sap.corp> References: <20060509172317.3d7915e7.mba2000@ioplex.com> <200605092143.XAA05375@uw1048.wdf.sap.corp> X-Mailer: Sylpheed version 1.0.6 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.6 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: kitten@ietf.org, Nicolas.Williams@sun.com Subject: Re: I18N & L10N proposal for GSS-API (v2u2/v3) 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, 9 May 2006 23:43:34 +0200 (MET DST) Martin Rex wrote: > The problem is if the existing code does some amount of parsing on > the string and looks for particular occurrances of certain ASCII > characters in strings, not knowing whether it is dealing with > a single-byte codepage or a traditional multibyte codepage, > because the trail byte of such a multibyte codepage can be > confused with a regular ASCII character. UTF-8 is safe because > with UTF-8, every octet of a multi-byte character as the highest bit set. Pardon me for hopping along half way through this thread but are you suggesting that users should be forced to convert all text to UTF-8? Meaning functions like gss_display_name would require UTF-8 as input? If so, then I doubt people will actually implement that. Let's think about the two cases: Case 1: Force UTF-8 Program possibly converts to/from UTF-8 to talk to gssapi AND have the mechanism lib possibly convert to/from UTF-8 to talk to the lib backing the mech. Case 2: Use the Locale Dependent Encoding Have the mechanism lib possibly convert to/from the locale dependent encoding to talk to the lib backing the mech. > MIT Kerberos 5 does definitely have such a problem with the realm seperator > "@" character -- and every GSS-API mechanism that implement the hostbased > service nametype and is locale-ignorant will also have this problem with > this nametype. I don't think GSSAPI should try to make up for deficiencies in other libraries thereby pushing the burden further up the chain onto users. If you do that I'm going to invest in neck braces :-> Mike _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue May 09 18:34:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fdamr-0002LJ-7E; Tue, 09 May 2006 18:34:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fdamp-0002LA-Rt for kitten@ietf.org; Tue, 09 May 2006 18:34:35 -0400 Received: from nwkea-mail-4.sun.com ([192.18.42.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fdamo-0001ae-Db for kitten@ietf.org; Tue, 09 May 2006 18:34:35 -0400 Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by nwkea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id k49MYXUm017664 for ; Tue, 9 May 2006 15:34:33 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k49MYAtk001368 for ; Tue, 9 May 2006 16:34: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 k49MYWmm029042; Tue, 9 May 2006 17:34:32 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k49MYVkk029041; Tue, 9 May 2006 17:34:31 -0500 (CDT) Date: Tue, 9 May 2006 17:34:31 -0500 From: Nicolas Williams To: Michael B Allen Message-ID: <20060509223431.GD28647@binky.Central.Sun.COM> Mail-Followup-To: Michael B Allen , martin.rex@sap.com, kitten@ietf.org References: <20060509172317.3d7915e7.mba2000@ioplex.com> <200605092143.XAA05375@uw1048.wdf.sap.corp> <20060509181439.4961fc85.mba2000@ioplex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060509181439.4961fc85.mba2000@ioplex.com> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: kitten@ietf.org Subject: Re: I18N & L10N proposal for GSS-API (v2u2/v3) 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, May 09, 2006 at 06:14:39PM -0400, Michael B Allen wrote: > On Tue, 9 May 2006 23:43:34 +0200 (MET DST) > Martin Rex wrote: > > Pardon me for hopping along half way through this thread but are > you suggesting that users should be forced to convert all text to > UTF-8? Meaning functions like gss_display_name would require UTF-8 as > input? If so, then I doubt people will actually implement that. Let's > think about the two cases: > > Case 1: Force UTF-8 > Program possibly converts to/from UTF-8 to talk to gssapi AND have > the mechanism lib possibly convert to/from UTF-8 to talk to the lib > backing the mech. > > Case 2: Use the Locale Dependent Encoding > Have the mechanism lib possibly convert to/from the locale dependent > encoding to talk to the lib backing the mech. Exactly. Case 2 is going to be preferable for application developers on platforms where there is such a concept as 'locales'. Martin may complain that this means that such applications are less portable, but that is a choice to be made by the application developer... ..And my proposal gives framework/mechanism implementors the choice of whether to force app developers to use UTF-8 or give app developers the choice of using UTF-8 explicitly or the CES of the current locale. For all the POSIX-like platforms and because framework/mechanism implementors will generally have to deal with codeset/normalization/ stringprep issues directly, I suspect that framework/mechanism implementors will provide the latter choice, and that application developers on POSIX-like platforms will take the ces-of-current-locale option, which will not significantly hinder portability to other platforms that are more in tune with Unicode already. > > MIT Kerberos 5 does definitely have such a problem with the realm seperator > > "@" character -- and every GSS-API mechanism that implement the hostbased > > service nametype and is locale-ignorant will also have this problem with > > this nametype. > > I don't think GSSAPI should try to make up for deficiencies in > other libraries thereby pushing the burden further up the chain onto > users. The particular "deficiency" Martin was discussing in the text you quote is not something applications can fix for the mechanism, period. Forcing the use of UTF-8 at the API does NOT make all instances of that sort of problem go away, and the mechanism MUST deal with normalization, prohibited codepoints, unassigned codepoints, etc... > If you do that I'm going to invest in neck braces :-> Exactly. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue May 09 20:00:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fdc7c-0002jG-VD; Tue, 09 May 2006 20:00:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fdc7b-0002jA-9i for kitten@ietf.org; Tue, 09 May 2006 20:00:07 -0400 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fdc7Y-0005Oj-TA for kitten@ietf.org; Tue, 09 May 2006 20:00:07 -0400 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id CAA20920; Wed, 10 May 2006 02:00:01 +0200 (MESZ) From: Martin Rex Message-Id: <200605100000.CAA08806@uw1048.wdf.sap.corp> To: mba2000@ioplex.com (Michael B Allen) Date: Wed, 10 May 2006 02:00:00 +0200 (MET DST) In-Reply-To: <20060509181439.4961fc85.mba2000@ioplex.com> from "Michael B Allen" at May 9, 6 06:14:39 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: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: kitten@ietf.org, Nicolas.Williams@sun.com Subject: Re: I18N & L10N proposal for GSS-API (v2u2/v3) 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 Michael B Allen wrote: > > Pardon me for hopping along half way through this thread but are > you suggesting that users should be forced to convert all text to > UTF-8? Meaning functions like gss_display_name would require UTF-8 as > input? For backward compatibility with GSS-API v2 based apps the original calls with (de-facto and spec-ignorant) implementation defined behaviour will still be present. Noone will force the application to use the utf8-variants of the three affected gssapi calls gss_import_name, gss_display_name and gss_display_status. btw. gss_display_name only has an opaque gss_name_t input handle, I assume you refer to gss_import_name with a printable nametype. > If so, then I doubt people will actually implement that. Let's > think about the two cases: > > Case 1: Force UTF-8 > Program possibly converts to/from UTF-8 to talk to gssapi AND have > the mechanism lib possibly convert to/from UTF-8 to talk to the lib > backing the mech. Someone will have to do a conversion between the codepage used by the user and the codepage used by the gssapi mechanism. Currently there are VERY few gssapi mechanism that are doing codepage conversions (and capable of doing it for arbitrary, user-chosen locales). > > Case 2: Use the Locale Dependent Encoding > Have the mechanism lib possibly convert to/from the locale dependent > encoding to talk to the lib backing the mech. can be done through the legacy API with all the known problems, i.e. what to do with non-representable chars, what about unsupported locales, ... Nico answered: : Forcing the use of UTF-8 at the API does NOT make all instances of that : sort of problem go away, and the mechanism MUST deal with normalization, : prohibited codepoints, unassigned codepoints, etc... When adding _utf8 support into my gsskrb5.dll I'm going to let Microsoft's APIs fight that out, and if I was a gssapi mechanism implementor I would ignore normalization and unassigned codepoints, just do a basic check whether it appears to be corretly encoded (i.e. if it only contains ASCII plus appropriately formed multi-byte sequences). -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue May 09 21:19:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FddLo-0002F1-PB; Tue, 09 May 2006 21:18:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FddLn-0002Ev-Cl for kitten@ietf.org; Tue, 09 May 2006 21:18:51 -0400 Received: from li4-142.members.linode.com ([66.220.1.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FddLm-0008M2-2S for kitten@ietf.org; Tue, 09 May 2006 21:18:51 -0400 Received: from quark.foo.net (c-69-142-196-170.hsd1.nj.comcast.net [69.142.196.170]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by li4-142.members.linode.com (Postfix) with ESMTP id ADF7442B69; Tue, 9 May 2006 21:18:40 -0400 (EDT) Date: Tue, 9 May 2006 21:16:24 -0400 From: Michael B Allen To: martin.rex@sap.com Message-Id: <20060509211624.20eb871f.mba2000@ioplex.com> In-Reply-To: <200605100000.CAA08806@uw1048.wdf.sap.corp> References: <20060509181439.4961fc85.mba2000@ioplex.com> <200605100000.CAA08806@uw1048.wdf.sap.corp> X-Mailer: Sylpheed version 1.0.6 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.6 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: kitten@ietf.org, Nicolas.Williams@sun.com Subject: Re: I18N & L10N proposal for GSS-API (v2u2/v3) 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, 10 May 2006 02:00:00 +0200 (MET DST) Martin Rex wrote: > > Case 1: Force UTF-8 > > Program possibly converts to/from UTF-8 to talk to gssapi AND have > > the mechanism lib possibly convert to/from UTF-8 to talk to the lib > > backing the mech. > > Someone will have to do a conversion between the codepage used > by the user and the codepage used by the gssapi mechanism. Right. That's why Case 2 is superior - no conversion between user and gssapi. > > Case 2: Use the Locale Dependent Encoding > > Have the mechanism lib possibly convert to/from the locale dependent > > encoding to talk to the lib backing the mech. > > can be done through the legacy API with all the known problems, > i.e. what to do with non-representable chars, what about > unsupported locales, ... I understand what you're saying but I don't understand how you came to the conclusion that requiring conversion to UTF-8 or somehow using UTF-8 internally would be a good idea. There's no end of arguments against it: 1) UTF-8 in itself isn't going to help with non-representable chars or unsupported locales or anything like that anyway because you get out of gssapi what you put in to gssapi. Forcing UTF-8 is just going to push the problem out of libgssapi up into the hands of annoyed programmers. 2) If you're not running in the UTF-8 locale you probably have a really good reason (e.g. Japanese) in which case the programmer/admin/user is in a much better position to setup the environment to yield the correct behavior. 3) Think about java.lang.String (UCS-2LE), Win32 UNICODE_STRING (UTF-16LE), C++ strings (UTF-16), etc. Even talking about UTF-8 in the context of these environments makes no sense. GSSAPI implementations are going to use whatever the premier string type is for the target environment / language (i.e. no one will implement it). Mike _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue May 09 21:19:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FddMf-0003PO-BG; Tue, 09 May 2006 21:19:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FddMe-0003NS-3c for kitten@ietf.org; Tue, 09 May 2006 21:19:44 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FddMb-0008NW-PC for kitten@ietf.org; Tue, 09 May 2006 21:19:44 -0400 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id k4A1JfKe022678 for ; Tue, 9 May 2006 19:19:41 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k4A1JeV5004866 for ; Tue, 9 May 2006 19:19: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 k4A1JeRB029146; Tue, 9 May 2006 20:19:40 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k4A1JepM029145; Tue, 9 May 2006 20:19:40 -0500 (CDT) Date: Tue, 9 May 2006 20:19:40 -0500 From: Nicolas Williams To: Martin Rex Message-ID: <20060510011939.GJ28647@binky.Central.Sun.COM> Mail-Followup-To: Martin Rex , Michael B Allen , kitten@ietf.org References: <20060509181439.4961fc85.mba2000@ioplex.com> <200605100000.CAA08806@uw1048.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200605100000.CAA08806@uw1048.wdf.sap.corp> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: kitten@ietf.org Subject: Re: I18N & L10N proposal for GSS-API (v2u2/v3) 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, May 10, 2006 at 02:00:00AM +0200, Martin Rex wrote: > Nico answered: > : Forcing the use of UTF-8 at the API does NOT make all instances of that > : sort of problem go away, and the mechanism MUST deal with normalization, > : prohibited codepoints, unassigned codepoints, etc... > > When adding _utf8 support into my gsskrb5.dll I'm going to let ^^^^^^^^^^^ Is that an implementation of RFC4121? If so... > Microsoft's APIs fight that out, and if I was a gssapi mechanism > implementor I would ignore normalization and unassigned codepoints, > just do a basic check whether it appears to be corretly encoded > (i.e. if it only contains ASCII plus appropriately formed > multi-byte sequences). ...sorry, it's not that easy. Kerberos V I18N will involve applications of stringprep, including normalization, prohibited codepoints, mapped codepoints, etc... (Now, if we make Kerberos V I18N something that only works with Kerberos V extensions then we might get away with not stringprepping principal names on the client side, but youd' still have to stringprep passwords for password-based pre-authentication. BTW, I'm a little rusty on krb5 I18N.) Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue May 09 21:26:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FddSx-0005l5-0C; Tue, 09 May 2006 21:26:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FddSv-0005kx-U7 for kitten@ietf.org; Tue, 09 May 2006 21:26:13 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FddSu-0000Mh-Jr for kitten@ietf.org; Tue, 09 May 2006 21:26:13 -0400 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id k4A1QCxW016433 for ; Tue, 9 May 2006 19:26:12 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k4A1QB82006523 for ; Tue, 9 May 2006 19:26: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 k4A1QBo9029155; Tue, 9 May 2006 20:26:11 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k4A1QBZ2029154; Tue, 9 May 2006 20:26:11 -0500 (CDT) Date: Tue, 9 May 2006 20:26:11 -0500 From: Nicolas Williams To: Michael B Allen Message-ID: <20060510012610.GK28647@binky.Central.Sun.COM> Mail-Followup-To: Michael B Allen , martin.rex@sap.com, kitten@ietf.org References: <20060509181439.4961fc85.mba2000@ioplex.com> <200605100000.CAA08806@uw1048.wdf.sap.corp> <20060509211624.20eb871f.mba2000@ioplex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060509211624.20eb871f.mba2000@ioplex.com> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: kitten@ietf.org Subject: Re: I18N & L10N proposal for GSS-API (v2u2/v3) 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, May 09, 2006 at 09:16:24PM -0400, Michael B Allen wrote: > On Wed, 10 May 2006 02:00:00 +0200 (MET DST) > Martin Rex wrote: > > can be done through the legacy API with all the known problems, > > i.e. what to do with non-representable chars, what about > > unsupported locales, ... > > I understand what you're saying but I don't understand how you came to > the conclusion that requiring conversion to UTF-8 or somehow using UTF-8 > internally would be a good idea. There's no end of arguments against it: BTW, it can be useful to declare UTF-8 a common medium in the middle of certain systems. That's an approach we are going to take for filesystem I18N (the middle being between the syscall and VFS boundaries). > 1) UTF-8 in itself isn't going to help with non-representable chars > or unsupported locales or anything like that anyway because you get > out of gssapi what you put in to gssapi. Forcing UTF-8 is just going > to push the problem out of libgssapi up into the hands of annoyed > programmers. > 2) If you're not running in the UTF-8 locale you probably have a really > good reason (e.g. Japanese) in which case the programmer/admin/user > is in a much better position to setup the environment to yield the > correct behavior. Well, *we* (OS vendors/developers) should want you to use UTF-8 locales always -- it simplifies a lot of problems, and if we could do it in one fell swoop then it would make this problem go away :) > 3) Think about java.lang.String (UCS-2LE), Win32 UNICODE_STRING > (UTF-16LE), C++ strings (UTF-16), etc. Even talking about UTF-8 in the > context of these environments makes no sense. GSSAPI implementations > are going to use whatever the premier string type is for the target > environment / language (i.e. no one will implement it). Stepping back a bit, the *abstract* interfaces would probably be specified in terms of Unicode (version 4?), not including any particular encoding thereof. The C bindings of the *abstract* interfaces would be specified in terms of UTF-8. And so on. But, yes, I agree that specific language bindings will use whatever the language prefers. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue May 09 22:38:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdeaI-0006ly-5y; Tue, 09 May 2006 22:37:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdeaH-0006lt-Bt for kitten@ietf.org; Tue, 09 May 2006 22:37:53 -0400 Received: from au.padl.com ([203.13.32.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdeaC-0003of-Gt for kitten@ietf.org; Tue, 09 May 2006 22:37:53 -0400 Received: from au.padl.com (localhost.padl.com [127.0.0.1]) by au.padl.com (8.12.11/8.12.11) with ESMTP id k4A2bJZI080752; Wed, 10 May 2006 12:37:19 +1000 (EST) (envelope-from lukeh@au.padl.com) Received: (from lukeh@localhost) by au.padl.com (8.12.11/8.12.11/Submit) id k4A2bCG1080746; Wed, 10 May 2006 12:37:12 +1000 (EST) (envelope-from lukeh) From: Luke Howard Message-Id: <200605100237.k4A2bCG1080746@au.padl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Organization: PADL Software Pty Ltd To: mba2000@ioplex.com References: <20060509181439.4961fc85.mba2000@ioplex.com> <200605100000.CAA08806@uw1048.wdf.sap.corp> <20060509211624.20eb871f.mba2000@ioplex.com> Date: Wed, 10 May 2006 12:37:12 +1000 Versions: dmail (bsd44) 2.6d/makemail 2.10 X-Spam-Status: No, hits=0.3 required=5.0 tests=UPPERCASE_25_50 autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on au.padl.com X-Spam-Score: 0.2 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: kitten@ietf.org, Nicolas.Williams@sun.com Subject: Re: I18N & L10N proposal for GSS-API (v2u2/v3) X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lukeh@padl.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 >3) Think about java.lang.String (UCS-2LE), Win32 UNICODE_STRING > (UTF-16LE), C++ strings (UTF-16), etc. Even talking about UTF-8 in the UNICODE_STRING is UCS-2LE, no? -- Luke -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue May 09 23:19:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdfEd-0000bP-Tc; Tue, 09 May 2006 23:19:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdfEc-0000bK-PR for kitten@ietf.org; Tue, 09 May 2006 23:19:34 -0400 Received: from li4-142.members.linode.com ([66.220.1.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdfEb-0005Nr-Ch for kitten@ietf.org; Tue, 09 May 2006 23:19:34 -0400 Received: from quark.foo.net (c-69-142-196-170.hsd1.nj.comcast.net [69.142.196.170]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by li4-142.members.linode.com (Postfix) with ESMTP id D357142C27; Tue, 9 May 2006 23:19:27 -0400 (EDT) Date: Tue, 9 May 2006 23:17:08 -0400 From: Michael B Allen To: Nicolas Williams Message-Id: <20060509231708.4ec70cc2.mba2000@ioplex.com> In-Reply-To: <20060510012610.GK28647@binky.Central.Sun.COM> References: <20060509181439.4961fc85.mba2000@ioplex.com> <200605100000.CAA08806@uw1048.wdf.sap.corp> <20060509211624.20eb871f.mba2000@ioplex.com> <20060510012610.GK28647@binky.Central.Sun.COM> X-Mailer: Sylpheed version 1.0.6 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.6 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: kitten@ietf.org Subject: Re: I18N & L10N proposal for GSS-API (v2u2/v3) 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, 9 May 2006 20:26:11 -0500 Nicolas Williams wrote: > BTW, it can be useful to declare UTF-8 a common medium in the middle of > certain systems. That's an approach we are going to take for filesystem > I18N (the middle being between the syscall and VFS boundaries). Would that be a library used by a single process like GSSAPI? If you were writing UTF-8 to the filesystem then I might agree with your design as a filesystem is a form of interprocess messaging. However, it does not sound like interprocess communication is involved and therefore unless there is intense string manipulation required, such as case insensitive path matching, I'm not certain I would agree. Of course I don't know the details. > > 2) If you're not running in the UTF-8 locale you probably have a really > > good reason (e.g. Japanese) in which case the programmer/admin/user > > is in a much better position to setup the environment to yield the > > correct behavior. > > Well, *we* (OS vendors/developers) should want you to use UTF-8 locales > always -- it simplifies a lot of problems, and if we could do it in one > fell swoop then it would make this problem go away :) CJK in UTF-8 requires 3 bytes per character. Expect resistance. You guys make it sound like there's something "wrong" with non-UTF-8 locales and that everything else is "legacy". There are many environments that do not use UTF-8 (or Unicode for that matter) for legitimate reasons. That might limit their interoperability but these days that's usually a consciencous decision. > Stepping back a bit, the *abstract* interfaces would probably be > specified in terms of Unicode (version 4?), not including any particular > encoding thereof. > > The C bindings of the *abstract* interfaces would be specified in terms > of UTF-8. And so on. So you do advocate requiring UTF-8? Mmm, for a minute there I thought we were in the same camp :-/ First, I want to reiterate that for encoding of network protocol messages I *am* advocating UTF-8 wherever possible. It's the library interface that I think should use the C locale encoding. So not all of the code needs to worry about locale dependent encodings. Ultimately all I'm really talking about is adding some mbrtowc(3) loops here and there. The implications for the code are not that bad for GSSAPI. In fact I wouldn't be surprised if the GSSAPI layer itself works fine as is, and that it's the mechanisms that need the attention. In that case the library backing the mechanism should be fixed or wrapped. In a sentence, I advocate requiring UTF-8 if there's interprocess messaging or if there's string manipulation that is otherwise difficult to perform with plain mbrtowc(3) loops. Otherwise, respect my locale! But then again, I'm a newbie here. Maybe I'm missing something important. Mike _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue May 09 23:25:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdfKZ-00038g-Ee; Tue, 09 May 2006 23:25:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdfKY-00038b-8d for kitten@ietf.org; Tue, 09 May 2006 23:25:42 -0400 Received: from li4-142.members.linode.com ([66.220.1.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdfKY-0005nv-14 for kitten@ietf.org; Tue, 09 May 2006 23:25:42 -0400 Received: from quark.foo.net (c-69-142-196-170.hsd1.nj.comcast.net [69.142.196.170]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by li4-142.members.linode.com (Postfix) with ESMTP id 886B642C27; Tue, 9 May 2006 23:25:40 -0400 (EDT) Date: Tue, 9 May 2006 23:23:24 -0400 From: Michael B Allen To: lukeh@padl.com Message-Id: <20060509232324.3fc07b1b.mba2000@ioplex.com> In-Reply-To: <200605100237.k4A2bCG1080746@au.padl.com> References: <20060509181439.4961fc85.mba2000@ioplex.com> <200605100000.CAA08806@uw1048.wdf.sap.corp> <20060509211624.20eb871f.mba2000@ioplex.com> <200605100237.k4A2bCG1080746@au.padl.com> X-Mailer: Sylpheed version 1.0.6 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.6 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: kitten@ietf.org, Nicolas.Williams@sun.com Subject: Re: I18N & L10N proposal for GSS-API (v2u2/v3) 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, 10 May 2006 12:37:12 +1000 Luke Howard wrote: > > >3) Think about java.lang.String (UCS-2LE), Win32 UNICODE_STRING > > (UTF-16LE), C++ strings (UTF-16), etc. Even talking about UTF-8 in the > > UNICODE_STRING is UCS-2LE, no? You could be right about that. I'm honestly not certain. I know it used to be UCS-2LE but I think MS has started to use UTF-16LE all over so I refuse to believe that somehow they've managed to keep their peas and carrots separate. Mike _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed May 10 00:54:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fdgin-0003o1-Dj; Wed, 10 May 2006 00:54:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fdgim-0003nw-HO for kitten@ietf.org; Wed, 10 May 2006 00:54:48 -0400 Received: from chokecherry.srv.cs.cmu.edu ([128.2.185.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fdgij-00018U-Ak for kitten@ietf.org; Wed, 10 May 2006 00:54:48 -0400 Received: from mariner.pc.cs.cmu.edu (MARINER.PC.CS.CMU.EDU [128.2.200.130]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.5/8.13.5) with ESMTP id k4A4shPx026487 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 10 May 2006 00:54:44 -0400 (EDT) Date: Wed, 10 May 2006 00:54:43 -0400 From: Jeffrey Hutzelman To: Nicolas Williams , Martin Rex Message-ID: <2D7ECF8D915FB6D43E9D4616@mariner.pc.cs.cmu.edu> In-Reply-To: <20060509215537.GZ28647@binky.Central.Sun.COM> References: <20060509172317.3d7915e7.mba2000@ioplex.com> <200605092143.XAA05375@uw1048.wdf.sap.corp> <20060509215537.GZ28647@binky.Central.Sun.COM> Originator-Info: login-token=Mulberry:01twPm5CFrW1gDTl5l6oEWU051HQ8+N18keBRJ7YM=; 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: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: kitten@ietf.org Subject: Re: I18N & L10N proposal for GSS-API (v2u2/v3) 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 Tuesday, May 09, 2006 04:55:37 PM -0500 Nicolas Williams wrote: > I don't want us discussing Kerberos V I18N Nor do I. Let's save that discussion for the appropriate time and place, and for _after_ reading draft-ietf-krb-wg-rfc1510ter (which, unfortunately, seems to have expired. I guess I'll be prodding the editor about that). -- Jeff, krb-wg chair _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed May 10 01:43:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdhU6-000526-7M; Wed, 10 May 2006 01:43:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdhSV-0004bD-3Z for kitten@ietf.org; Wed, 10 May 2006 01:42:03 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdhIP-0002Rm-I0 for kitten@ietf.org; Wed, 10 May 2006 01:31:37 -0400 Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id k4A5VaKe002386 for ; Tue, 9 May 2006 23:31:37 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k4A5VDcE026248 for ; Tue, 9 May 2006 23:31:13 -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 k4A5Vaw3029355; Wed, 10 May 2006 00:31:36 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k4A5VYUh029354; Wed, 10 May 2006 00:31:34 -0500 (CDT) Date: Wed, 10 May 2006 00:31:34 -0500 From: Nicolas Williams To: Michael B Allen Message-ID: <20060510053134.GN28647@binky.Central.Sun.COM> Mail-Followup-To: Michael B Allen , martin.rex@sap.com, kitten@ietf.org References: <20060509181439.4961fc85.mba2000@ioplex.com> <200605100000.CAA08806@uw1048.wdf.sap.corp> <20060509211624.20eb871f.mba2000@ioplex.com> <20060510012610.GK28647@binky.Central.Sun.COM> <20060509231708.4ec70cc2.mba2000@ioplex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060509231708.4ec70cc2.mba2000@ioplex.com> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: kitten@ietf.org Subject: Re: I18N & L10N proposal for GSS-API (v2u2/v3) 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, May 09, 2006 at 11:17:08PM -0400, Michael B Allen wrote: > On Tue, 9 May 2006 20:26:11 -0500 > Nicolas Williams wrote: > > > BTW, it can be useful to declare UTF-8 a common medium in the middle of > > certain systems. That's an approach we are going to take for filesystem > > I18N (the middle being between the syscall and VFS boundaries). > > Would that be a library used by a single process like GSSAPI? If you > were writing UTF-8 to the filesystem then I might agree with your design > as a filesystem is a form of interprocess messaging. However, it does not > sound like interprocess communication is involved and therefore unless > there is intense string manipulation required, such as case insensitive > path matching, I'm not certain I would agree. Of course I don't know > the details. That was an aside, not to be taken as justification for anything in regards to the GSS-API. > > > 2) If you're not running in the UTF-8 locale you probably have a really > > > good reason (e.g. Japanese) in which case the programmer/admin/user > > > is in a much better position to setup the environment to yield the > > > correct behavior. > > > > Well, *we* (OS vendors/developers) should want you to use UTF-8 locales > > always -- it simplifies a lot of problems, and if we could do it in one > > fell swoop then it would make this problem go away :) > > CJK in UTF-8 requires 3 bytes per character. Expect resistance. I think there will be no resistance, but I'm not an I18N expert. > > Stepping back a bit, the *abstract* interfaces would probably be > > specified in terms of Unicode (version 4?), not including any particular > > encoding thereof. > > > > The C bindings of the *abstract* interfaces would be specified in terms > > of UTF-8. And so on. > > So you do advocate requiring UTF-8? Mmm, for a minute there I thought we > were in the same camp :-/ No, I advocate requiring that the API support the explicit use of UTF-8 and that optionally it support -just-use-current-locale's-ces. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed May 10 11:51:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdqyO-00050o-2e; Wed, 10 May 2006 11:51:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdqyM-0004yS-IH for kitten@ietf.org; Wed, 10 May 2006 11:51:34 -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 1FdqyM-00039i-Gl for kitten@ietf.org; Wed, 10 May 2006 11:51:34 -0400 Received: from smtpde03.sap-ag.de ([155.56.68.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FdqiZ-0005lB-OK for kitten@ietf.org; Wed, 10 May 2006 11:35:17 -0400 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id RAA16788; Wed, 10 May 2006 17:35:05 +0200 (MESZ) From: Martin Rex Message-Id: <200605101535.RAA28032@uw1048.wdf.sap.corp> To: mba2000@ioplex.com (Michael B Allen) Date: Wed, 10 May 2006 17:35:05 +0200 (MET DST) In-Reply-To: <20060509231708.4ec70cc2.mba2000@ioplex.com> from "Michael B Allen" at May 9, 6 11:17:08 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: -1.5 (-) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: kitten@ietf.org, Nicolas.Williams@sun.com Subject: Re: I18N & L10N proposal for GSS-API (v2u2/v3) 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 Michael B Allen wrote: > > Would that be a library used by a single process like GSSAPI? If you > were writing UTF-8 to the filesystem then I might agree with your design > as a filesystem is a form of interprocess messaging. However, it does not > sound like interprocess communication is involved and therefore unless > there is intense string manipulation required, such as case insensitive > path matching, I'm not certain I would agree. Of course I don't know > the details. Well, we and a lot of others use GSS-API to protect the communication between two distinct entities, a communication initiator and a communication acceptor. These two might use IPC for communication, but it is going to be a "network communication" quite often. The authentication service provided by the GSS-API mechanism usually conveys the identity of the initiator (taken from the credentials of the initiator) to the acceptor somewhere within a context level token that is emitted by gss_init_sec_context() of the initiators gssapi implementation and to be consumed by gss_accept_sec_context() of the acceptors gssapi implementation. When mutual authentication is requested or provided, this also works in the other direction (just that the initiator has to supply the expected identity of the acceptor to the initial call of gss_init_sec_context() and the gssapi mechanism performs the comparison/matching (authentication) against the conveyed identity. So in the general case, as far as the names of the identies of initator and acceptor involved, there are two, potentially differing locales involved--maybe even a third locale of a trusted third party like a KDC which participates the authentication procedure. > > > > 2) If you're not running in the UTF-8 locale you probably have a really > > > good reason (e.g. Japanese) in which case the programmer/admin/user > > > is in a much better position to setup the environment to yield the > > > correct behavior. > > > > Well, *we* (OS vendors/developers) should want you to use UTF-8 locales > > always -- it simplifies a lot of problems, and if we could do it in one > > fell swoop then it would make this problem go away :) > > CJK in UTF-8 requires 3 bytes per character. Expect resistance. > > You guys make it sound like there's something "wrong" with non-UTF-8 > locales and that everything else is "legacy". There are many environments > that do not use UTF-8 (or Unicode for that matter) for legitimate > reasons. That might limit their interoperability but these days that's > usually a consciencous decision. Not really. But there's a requirement in the IETF to address I18N in all standards, and also a requirement for a mandatory-to-implement variant -- and most standards have settled on UTF-8 for that purpose. As I mentioned before, there are a lot of SPKM- and proprietary SPKM-like gssapi mechanisms out there using an X.509 PKI for authentication and X.509 happens to use almost exclusively the encodings from one of 7-bit ASCII, ISO-Latin1 (abused T61string), and UTF8String. Microsoft has chosen to use UTF-8 for Kerberos principal names. There is little chance that we could sneak a GSS-API v3 past the IESG without addressing I18N and without exactly one mandatory-to-implement encoding that will allow I18N -- which more or less boils down to a Unicode encoding. IMHO, UTF-8 seems to be the most reasonable choice here. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed May 10 12:41:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdrkM-0005Ps-Ut; Wed, 10 May 2006 12:41:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdrkM-0005Pn-Et for kitten@ietf.org; Wed, 10 May 2006 12:41:10 -0400 Received: from li4-142.members.linode.com ([66.220.1.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdrkM-0005qF-1b for kitten@ietf.org; Wed, 10 May 2006 12:41:10 -0400 Received: from quark.foo.net (c-69-142-196-170.hsd1.nj.comcast.net [69.142.196.170]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by li4-142.members.linode.com (Postfix) with ESMTP id BF5B942B83; Wed, 10 May 2006 12:41:00 -0400 (EDT) Date: Wed, 10 May 2006 12:38:39 -0400 From: Michael B Allen To: martin.rex@sap.com Message-Id: <20060510123839.242e05b7.mba2000@ioplex.com> In-Reply-To: <200605101535.RAA28032@uw1048.wdf.sap.corp> References: <20060509231708.4ec70cc2.mba2000@ioplex.com> <200605101535.RAA28032@uw1048.wdf.sap.corp> X-Mailer: Sylpheed version 1.0.6 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.6 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: kitten@ietf.org, Nicolas.Williams@sun.com Subject: Re: I18N & L10N proposal for GSS-API (v2u2/v3) 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, 10 May 2006 17:35:05 +0200 (MET DST) Martin Rex wrote: > > > > 2) If you're not running in the UTF-8 locale you probably have a really > > > > good reason (e.g. Japanese) in which case the programmer/admin/user > > > > is in a much better position to setup the environment to yield the > > > > correct behavior. > > > > > > Well, *we* (OS vendors/developers) should want you to use UTF-8 locales > > > always -- it simplifies a lot of problems, and if we could do it in one > > > fell swoop then it would make this problem go away :) > > > > CJK in UTF-8 requires 3 bytes per character. Expect resistance. > > > > You guys make it sound like there's something "wrong" with non-UTF-8 > > locales and that everything else is "legacy". There are many environments > > that do not use UTF-8 (or Unicode for that matter) for legitimate > > reasons. That might limit their interoperability but these days that's > > usually a consciencous decision. > > Not really. But there's a requirement in the IETF to address I18N > in all standards, and also a requirement for a mandatory-to-implement > variant -- and most standards have settled on UTF-8 for that purpose. > > As I mentioned before, there are a lot of SPKM- and proprietary SPKM-like > gssapi mechanisms out there using an X.509 PKI for authentication > and X.509 happens to use almost exclusively the encodings from > one of 7-bit ASCII, ISO-Latin1 (abused T61string), and UTF8String. > Microsoft has chosen to use UTF-8 for Kerberos principal names. > > > There is little chance that we could sneak a GSS-API v3 past the IESG > without addressing I18N and without exactly one mandatory-to-implement > encoding that will allow I18N -- which more or less boils down to > a Unicode encoding. IMHO, UTF-8 seems to be the most reasonable > choice here. I completely agree that you want to be fully internationalized. Obviously. It's a great mandate. I'm just trying to explain as a programmer who has written i18n consciencous code how to do that politely. Again, the GSSAPI layer itself is fine right now as is [1]. It's the *mechs* that need attention. If the library backing the mech is providing Latin1 strings with umlauts and the user is in the UTF-8 locale and the mech is simply using strcpy, then that's just a bug in the mechanism. Plain and simple BUG. Those bugs can be fixed by either "fixing" the library backing the mech (hint: MS has done us a favor by using UTF-8) or wrapping it's functions to convert to the locale dependent encoding. I say, convert at the mech boundy once. If you mandate UTF-8 regardless of locale then you still have to convert at the mech boundry AND then the program has to convert again at the GSSAPI user API. If you want to push the i18n boundry a little, mandate that mech boundries properly convert to the locale dependent encoding. For example, let's say you have some SPKM mech that's doing Latin1 but the user is using a ISO-8859-4 locale [2]. By the new mandate the mech is required to convert all Latin1 strings to ISO-8859-4 (using iconv(3) presumably). Done. You might get EILSEQ errors or '?' marks in your string but that should just indicate to the admin/user that they should upgrade to the UTF-8 locale or dodge those characters. Mike [1] If not all it needs are probably a few mbrtowc loops. [2] I don't think Latin1 and ISO-8859-4 are fully compatible but play along and assume that the programmer/admin/user knew what they were doing or had a really good reason for chosing that locale. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed May 10 13:07:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fds9j-0000dN-8h; Wed, 10 May 2006 13:07:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fds9g-0000ZF-MM for kitten@ietf.org; Wed, 10 May 2006 13:07:20 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fds1Z-0006tK-MJ for kitten@ietf.org; Wed, 10 May 2006 12:58:59 -0400 Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id k4AGwvKe005795 for ; Wed, 10 May 2006 10:58:57 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k4AGwWWx023218 for ; Wed, 10 May 2006 10:58: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 k4AGwuAl029724; Wed, 10 May 2006 11:58:56 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k4AGwtLc029723; Wed, 10 May 2006 11:58:55 -0500 (CDT) Date: Wed, 10 May 2006 11:58:55 -0500 From: Nicolas Williams To: Martin Rex Message-ID: <20060510165855.GW28647@binky.Central.Sun.COM> Mail-Followup-To: Martin Rex , Michael B Allen , kitten@ietf.org References: <20060509231708.4ec70cc2.mba2000@ioplex.com> <200605101535.RAA28032@uw1048.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200605101535.RAA28032@uw1048.wdf.sap.corp> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: kitten@ietf.org Subject: Re: I18N & L10N proposal for GSS-API (v2u2/v3) 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, May 10, 2006 at 05:35:05PM +0200, Martin Rex wrote: > As I mentioned before, there are a lot of SPKM- and proprietary SPKM-like > gssapi mechanisms out there using an X.509 PKI for authentication > and X.509 happens to use almost exclusively the encodings from > one of 7-bit ASCII, ISO-Latin1 (abused T61string), and UTF8String. > Microsoft has chosen to use UTF-8 for Kerberos principal names. Is PKI properly internationalized? Kerberos V isn't, and what MS does is not correct. (Again, wrong forum for that discussion.) > There is little chance that we could sneak a GSS-API v3 past the IESG > without addressing I18N and without exactly one mandatory-to-implement > encoding that will allow I18N -- which more or less boils down to > a Unicode encoding. IMHO, UTF-8 seems to be the most reasonable > choice here. I can imagine a programming language where UTF-8 would not be the right choice. This is an API, not a protocol (protocol I18N considerations belong in the mechs), so mandates to use UTF-8, stringprep, etc. don't apply, only a mandate to ensure I18N and L10N should apply. Now, I do agree that UTF-8 is the way of the future, but until we deprecate non-UTF-8 locales I'll be reluctant to have a UTF-8-only API, and a Latin-1-only alternative is NOT sufficient either. It's pretty simple: - we agree on requiring support only for Unicode in the API, with appropriate language-specific bindings (e.g., UTF-8 for C bindings), but: - I also insist on an optional locale's-current-codeset option because on POSIX/POSIX-like platforms that is the most comfortable option for application developers. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed May 10 13:08:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdsAX-0001Lt-AI; Wed, 10 May 2006 13:08:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdsAS-0001EZ-OT for kitten@ietf.org; Wed, 10 May 2006 13:08:08 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdsAS-0007Ti-FN for kitten@ietf.org; Wed, 10 May 2006 13:08:08 -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 serrano.cc.columbia.edu (8.13.6/8.13.6) with ESMTP id k4AH85oF023522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 10 May 2006 13:08:07 -0400 (EDT) Message-ID: <44621DF0.3040205@columbia.edu> Date: Wed, 10 May 2006 13:08:00 -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: Michael B Allen References: <20060509231708.4ec70cc2.mba2000@ioplex.com> <200605101535.RAA28032@uw1048.wdf.sap.corp> <20060510123839.242e05b7.mba2000@ioplex.com> In-Reply-To: <20060510123839.242e05b7.mba2000@ioplex.com> X-Enigmail-Version: 0.94.0.0 X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Cc: kitten@ietf.org, Nicolas.Williams@sun.com Subject: Re: I18N & L10N proposal for GSS-API (v2u2/v3) 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="===============2080828177==" Errors-To: kitten-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============2080828177== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050909030901000509050106" This is a cryptographically signed message in MIME format. --------------ms050909030901000509050106 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Michael: GSS-API v2 upd 1 requires that all strings used for input and output be ISO-Latin-1. This is the requirement today. It is a bug for any mechanism to be returning anything other than ISO-Latin-1. It is also a bug for any application to provide as input anything other than ISO-Latin-1. As it turns out, most applications ignore this requirement as do most mechanisms. That does not change what the requirement as stated by the RFC is. These implementations "just-use-8" today and hope for the best. For GSS-APIv3 we can choose to do something different. What I am wondering is whether we need to define both a GSS-API and a GSS-SPI. The layer that implements both the GSS-API and the GSS-SPI would be responsible for handling translation from locale to UTF8 and mechanisms (which would only implement the GSS-SPI) would be required to handle UTF8 on their boundary. In this model I would prefer the GSS-API to have separate locale and utf8 variants. The locale variants would be allowed to return an error if locale to utf8 translation services are not available. I do not believe it is necessary for the GSS-API to support arbitrary character-set as input and I would prefer to avoid creating another character-set registry. Jeffrey Altman (speaking as an individual) Michael B Allen wrote: > I completely agree that you want to be fully > internationalized. Obviously. It's a great mandate. I'm just trying to > explain as a programmer who has written i18n consciencous code how to > do that politely. > > Again, the GSSAPI layer itself is fine right now as is [1]. It's > the *mechs* that need attention. If the library backing the mech is > providing Latin1 strings with umlauts and the user is in the UTF-8 > locale and the mech is simply using strcpy, then that's just a bug in > the mechanism. Plain and simple BUG. Those bugs can be fixed by either > "fixing" the library backing the mech (hint: MS has done us a favor > by using UTF-8) or wrapping it's functions to convert to the locale > dependent encoding. > > I say, convert at the mech boundy once. If you mandate UTF-8 regardless > of locale then you still have to convert at the mech boundry AND then > the program has to convert again at the GSSAPI user API. > > If you want to push the i18n boundry a little, mandate that mech boundries > properly convert to the locale dependent encoding. > > For example, let's say you have some SPKM mech that's doing Latin1 but > the user is using a ISO-8859-4 locale [2]. By the new mandate the mech > is required to convert all Latin1 strings to ISO-8859-4 (using iconv(3) > presumably). Done. You might get EILSEQ errors or '?' marks in your > string but that should just indicate to the admin/user that they should > upgrade to the UTF-8 locale or dodge those characters. > > Mike > > [1] If not all it needs are probably a few mbrtowc loops. > [2] I don't think Latin1 and ISO-8859-4 are fully compatible but play > along and assume that the programmer/admin/user knew what they were > doing or had a really good reason for chosing that locale. > > _______________________________________________ > Kitten mailing list > Kitten@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/kitten --------------ms050909030901000509050106 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 DxcNMDYwNTEwMTcwODAwWjAjBgkqhkiG9w0BCQQxFgQULkgjbOLhLbC5A3Ukgzd4J/t/g9Aw UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw7NrDB6BgsqhkiG9w0B CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AgMOzawwDQYJKoZIhvcNAQEBBQAEggEAFCeYOWPPhhCIkSblRCFplWNef1HGZ4RJNK8bTNIi uhpUgandG7QCDTd4qMoX3H1Jnxb+7N8LNlFQgyv6oJWdP901+vw7CipjtAkh7AKRbRo8+C+5 XaXFGKNCW9a1VbSx98lndQPM3PpjUt4OI8E9mPKHRuUfrmlWE0nKx6087NOa71nUPs9m21S0 Cc7QyxzKDSMsaBcgk2kEHiNMwNErXBPKxskVoFGHA5iBnb5hHucicmZngMoT4Fad8H8hCGHF prwljItBBIgCN/YxCP00+D36YlOaFWqqvigAo3z3bAuxcCEKgCScj/lWD5MtKbriZuTMnCWJ sNuoWJdQabLyOwAAAAAAAA== --------------ms050909030901000509050106-- --===============2080828177== 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 --===============2080828177==-- From kitten-bounces@lists.ietf.org Wed May 10 13:11:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdsDO-0001cs-0s; Wed, 10 May 2006 13:11:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdsDM-0001cn-Pg for kitten@ietf.org; Wed, 10 May 2006 13:11:08 -0400 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdsDJ-0007Xb-BL for kitten@ietf.org; Wed, 10 May 2006 13:11:08 -0400 Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id k4AHB4if025664 for ; Wed, 10 May 2006 10:11:04 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k4AHAdYn029058 for ; Wed, 10 May 2006 11:10:39 -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 k4AHB3rC029743; Wed, 10 May 2006 12:11:03 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k4AHB3GD029742; Wed, 10 May 2006 12:11:03 -0500 (CDT) Date: Wed, 10 May 2006 12:11:03 -0500 From: Nicolas Williams To: Jeffrey Altman Message-ID: <20060510171102.GY28647@binky.Central.Sun.COM> Mail-Followup-To: Jeffrey Altman , Michael B Allen , kitten@ietf.org References: <20060509231708.4ec70cc2.mba2000@ioplex.com> <200605101535.RAA28032@uw1048.wdf.sap.corp> <20060510123839.242e05b7.mba2000@ioplex.com> <44621DF0.3040205@columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44621DF0.3040205@columbia.edu> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Cc: kitten@ietf.org Subject: Re: I18N & L10N proposal for GSS-API (v2u2/v3) 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, May 10, 2006 at 01:08:00PM -0400, Jeffrey Altman wrote: > I do not believe it is necessary for the GSS-API to support arbitrary > character-set as input and I would prefer to avoid creating another > character-set registry. No new registry would be required in my proposal. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed May 10 13:56:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdsvY-0003Ko-CC; Wed, 10 May 2006 13:56:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdsvW-0003Kj-E3 for kitten@ietf.org; Wed, 10 May 2006 13:56:46 -0400 Received: from chokecherry.srv.cs.cmu.edu ([128.2.185.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdsvW-0000zV-3P for kitten@ietf.org; Wed, 10 May 2006 13:56:46 -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 k4AHueFr012127 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 10 May 2006 13:56:44 -0400 (EDT) Date: Wed, 10 May 2006 13:56:40 -0400 From: Jeffrey Hutzelman To: Michael B Allen , martin.rex@sap.com Message-ID: <16D248503761D077DBEF38AF@sirius.fac.cs.cmu.edu> In-Reply-To: <20060510123839.242e05b7.mba2000@ioplex.com> References: <20060509231708.4ec70cc2.mba2000@ioplex.com> <200605101535.RAA28032@uw1048.wdf.sap.corp> <20060510123839.242e05b7.mba2000@ioplex.com> Originator-Info: login-token=Mulberry:01ufvZpCNjThgFRlEl7HkJE1BtEM9AL1ImcAcJ73s=; 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: b132cb3ed2d4be2017585bf6859e1ede Cc: kitten@ietf.org, Nicolas.Williams@sun.com Subject: Re: I18N & L10N proposal for GSS-API (v2u2/v3) 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, May 10, 2006 12:38:39 PM -0400 Michael B Allen wrote: > Again, the GSSAPI layer itself is fine right now as is [1]. It's > the *mechs* that need attention. If the library backing the mech is > providing Latin1 strings with umlauts and the user is in the UTF-8 > locale and the mech is simply using strcpy, then that's just a bug in > the mechanism. Plain and simple BUG.\ First of all, there generall is no "GSSAPI layer". The GSS-API is implemented directly by mechanisms. This provides for fun when you want to hve a multi-mechanism glue layer, but that's all behind the API and thus an implementation matter (i.e. out of scope for the GSS _API_ specification, which is what we are discussing on this list). Second, it's best not to think in terms of "the library backing the mech", because that introduces assumptions about what's behind the API which may not be in line with actual implementations. Sure, there are mechanisms that make use of libraries, but the GSS-API mechanism layer generally does a non-trivial amount of work, and there can be mechanisms where there is no such library. A better way to say this would be "If the mechanism uses Latin-1 on the wire and just returns wire strings to the app without conversion, and the user is in a UTF-8 locale, then that is a bug". Third, the behavior you describe is actually _not_ a bug, because the GSSAPIv2 spec explicitly requires the use of Latin-1. What would be a bug would be to fail to convert strings which are _not_ Latin-1 on the wire. Unfortunately, many existing implementations ignore this part of the spec, and instead either use whatever the current locale is for the API, converting between _that_ and whatever is used on the wire, or worse, do nothing at all, depending on the application to use the right encoding (and with some mechanisms, this works, as long as both ends behave that way and happen to use the same charset). What Martin is proposing, for the upcoming GSSAPIv3, is a new set of API's which are defined to use UTF-8 rather than Latin-1. The hope is that this time, both mechanisms and applications would actually stick to the spec, converting as needed between UTF-8 and whatever they actually want to use. What Nico is proposing, also for the upcoming GSSAPIv3, is a different new set of API's, which provide a way for the caller to explicitly indicate what charset he is using. It would then be up to the mechanism to convert between _that_ and whatever is needed on the wire. He further proposes initially defining two values for the charset parameter, with one meaning "utf-8", and the other meaning "whatever the current locale is". The advantages of either Martin's proposal or Nico's UTF-8 mode are the same: mechanisms need only deal with UTF-8, those mechanisms that use UTF-8 on the wire need not do charset conversion at all (though they will still need to do whatever stringprep or other transforms are required to implement the mechanism), and applications working with data in a known charset can get a consistent behavior from the GSS-API which does not depend on the environment in which the application is run. The advantages of Nico's current-locale mode is that applications which are working with data in a locale-dependent charset, including any data which is entered by or displayed to the user, can use a locale-dependent API which "just works" when presented with such data, and which plays nicely with the wide-variety of locale-dependent API's likely to exist on a locale-aware system(*). Now, Martin has objected that Nico's approach would require mechanisms to perform converstion (which it would, as would the UTF-8 approach, for mechanisms not using UTF-8 on the wire). This objection mostly seems to be based on the size of the code, and more significantly, the tables, required to perform such conversions. That would be a valid concern if every mechanism implementation had to contain a copy of that code and those tables. But the practical reality is that both applications and mechanisms are going to perform conversions using a system API provided for that purpose, so no matter what you do, the code and tables don't appear in either the application or mechanism implementation, but _do_ appear in the system. So, I do not find this argument compelling. Now, there are going to be issues with systems that provide no such interface. On those systems, there's going to be trouble no matter what you do, unless both the application and mechanism work exclusively in UTF-8. For well-desined mechanisms, you're still going to have a problem, because even a mechanism which never has to see a charset other than UTF-8 is still going to have to do string preparation, generally including Unicode string normalization, which requires its own tables of nontrivial size. And a platform that doesn't provide facilities for converting between UTF-8 and the locale-dependent charsets for whatever locales it supports is not going to provide facilities for Unicode normalization, either. Note that on a system where only Unicode is supported, one can simply declare the "locale-dependent charset" to always be UTF-8, and then both of Nico's proposed modes act identically. Myself, I very much like the idea that, in an environment which has locales and provides charset-conversion utilities, an application should be able to pass user-provided data expressed in the charset of the current locale directly to the API without having to deal with conversion. As Nico points out, there are or should be way more applications than mechanisms, and we should make life convenient for application programmers. I'm not saying that _every_ application should be forced to behave this way; each application should be able to choose the interface variant whcih works best for it. And I have to admit, I also like the idea of having an interface that is extensible in this dimension. Someday we're going to get conquered by technologically-advanced aliens who don't use Unicode, and we're going to have to support whatever charset they do use. (*) Yes, Martin, we know that in 1993 there weren't so many such API's and the world was a pretty sad place for people who wanted to actually use locales. However, the situation has changed, things work well today, and when designing a modern API it is reasonable to assume, to a certain extent, that the rest of the system is similarly modern. It is not reasonable to constrain the design of a new API based on the limitations of 13-year-old systems which are beyond their end-of-life and will never support the new API. -- Jeff _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed May 10 14:33:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdtVF-0003O5-Ti; Wed, 10 May 2006 14:33:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdtVF-0003O0-E6 for kitten@ietf.org; Wed, 10 May 2006 14:33:41 -0400 Received: from li4-142.members.linode.com ([66.220.1.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdtVC-0002sc-56 for kitten@ietf.org; Wed, 10 May 2006 14:33:41 -0400 Received: from quark.foo.net (c-69-142-196-170.hsd1.nj.comcast.net [69.142.196.170]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by li4-142.members.linode.com (Postfix) with ESMTP id 662AD42B83; Wed, 10 May 2006 14:33:30 -0400 (EDT) Date: Wed, 10 May 2006 14:31:09 -0400 From: Michael B Allen To: Jeffrey Altman Message-Id: <20060510143109.4b45f7fe.mba2000@ioplex.com> In-Reply-To: <44621DF0.3040205@columbia.edu> References: <20060509231708.4ec70cc2.mba2000@ioplex.com> <200605101535.RAA28032@uw1048.wdf.sap.corp> <20060510123839.242e05b7.mba2000@ioplex.com> <44621DF0.3040205@columbia.edu> X-Mailer: Sylpheed version 1.0.6 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.6 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: kitten@ietf.org, Nicolas.Williams@sun.com Subject: Re: I18N & L10N proposal for GSS-API (v2u2/v3) 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, 10 May 2006 13:08:00 -0400 Jeffrey Altman wrote: > For GSS-APIv3 we can choose to do something different. What I am > wondering is whether we need to define both a GSS-API and a GSS-SPI. > The layer that implements both the GSS-API and the GSS-SPI would be > responsible for handling translation from locale to UTF8 and mechanisms > (which would only implement the GSS-SPI) would be required to handle > UTF8 on their boundary. I see. So you're more concerned with mechglue mechanism interoperability? Is SPI "service provider interface"? Mike _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed May 10 14:36:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdtXw-0005Wz-Up; Wed, 10 May 2006 14:36:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdtXv-0005Wu-5t for kitten@ietf.org; Wed, 10 May 2006 14:36:27 -0400 Received: from chokecherry.srv.cs.cmu.edu ([128.2.185.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdtXu-00031J-Si for kitten@ietf.org; Wed, 10 May 2006 14:36:27 -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 k4AIaPbM013413 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 10 May 2006 14:36:25 -0400 (EDT) Date: Wed, 10 May 2006 14:36:25 -0400 From: Jeffrey Hutzelman To: Nicolas Williams , Martin Rex Message-ID: <6658CB1E326054A3C827621A@sirius.fac.cs.cmu.edu> In-Reply-To: <20060510165855.GW28647@binky.Central.Sun.COM> References: <20060509231708.4ec70cc2.mba2000@ioplex.com> <200605101535.RAA28032@uw1048.wdf.sap.corp> <20060510165855.GW28647@binky.Central.Sun.COM> Originator-Info: login-token=Mulberry:01rZSS/Bf8B3D53wp94BLCa0QGySc0yAsaCcBh4xQ=; 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: a7d2e37451f7f22841e3b6f40c67db0f Cc: kitten@ietf.org Subject: Re: I18N & L10N proposal for GSS-API (v2u2/v3) 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, May 10, 2006 11:58:55 AM -0500 Nicolas Williams wrote: > It's pretty simple: > > - we agree on requiring support only for Unicode in the API, with > appropriate language-specific bindings (e.g., UTF-8 for C bindings), > > but: > > - I also insist on an optional locale's-current-codeset option because > on POSIX/POSIX-like platforms that is the most comfortable option for > application developers. And after reading this discussion the past several days, I've decided that I support using an approach which provides for that additional mode. The real question is, what do you do when an application tries to use a mode that is not supported? And more importantly, how do you prevent that from happening too often? Particularly, for the situation Nico is talking about, it would be nice if applications built in certain environments could assume the current-locale mode will work. Ideally, it would be good if applications written for, say, POSIX, could simply assume the mode will work and thus not have to _have_ any code to deal with charset conversion. To this end, I'll suggest a few requirements: For the purposes of this proposal... The phrase "locale-aware" refers to an environment in which there is some concept of "locale" or of a current or default character set which can be configured either system-wide or separately for each user, session, process, or whatever, _and_ in which _either_ it is possible to tell at runtime what charset is in use, _or_ there are standard system-provided interfaces which support conversion between the charset in use and a fixed or caller-specified charset. The phrase "fixed-charset" refers to an environment in which only a single charset is used, and in which it is reasonable to expect that charset to be known at the time code is built for that environment. It is possible to have environments which are neither locale-aware nor fixed-charset. For example, a system whose interfaces all use UTF-8 exclusively is fixed-charset. But a system which uses exactly one charset based on which of several mutually-exclusive packages is installed is _not_ fixed-charset, because the same program can end up being expected to use different charsets depending on the environment in which it is run. Such an environment may be "locale-aware", if it is possible to tell at runtime which charset is in use, or if the system provides conversion routines between that cnarset and, say, UTF-8. "Unicode mode" refers to a mode of operation in which the GSS-API uses Unicode strings, in some encoding which may be dependent on the language environment (for example, I'd expect C-bindings to use UTF-8, but in some other language it might be more natural to use UCS2 or UTF-16). "Locale mode" refers to a mode of operation in which the strings used by GSS-API are expressed in a character set and encoding which depends on the environment. (1) All GSS-API implementations MUST support the Unicode mode. (2) In a fixed-charset environment which uses UTF-8 as the system charset, Locale mode MUST be supported and MUST use UTF-8. (3) In a fixed-charset environment which uses a system charset other than UTF-8, but which provides a mechanism for converting between the system charset and UTF-8, Locale mode MUST be supported and MUST use the system charset. (3) In other fixed-charset enviroments, Locale mode SHOULD be supported; if Locale mode is supported, it MUST use the system charset. (4) In a locale-aware environment which provides facilities that can be used to convert between the current charset and UTF-8, Locale mode MUST be supported and MUST use the current charset. Note that such facilities could consist of conversion functions which use the current charset implicitly, or of a generic conversion interface such as iconv() coupled, with a way to find the current charset. So basically, you always have to support Unicode, and you also have to support Locale mode if the system provides the facilities needed for mechanisms to do so in a reasonable way. This allows applications written for environments where such facilities are guaranteed to be available to make the assumption that Locale mode will be supported, without placing undue burden on mechanism implementors in environments where such facilities are not provided by the system. It would probably be nice to be able to tell at compile time whether the Locale mode will be supported. In C bindings, this might be done with a preprocessor symbol indicating support for Locale mode. I consider this a reasonable approach because we are standardizing an API, not an ABI; implementors who want to standardize an ABI and provide multiple mechanisms supporting that ABI may have to introduce further constraints. -- Jeff _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed May 10 14:47:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fdti5-0000P2-5B; Wed, 10 May 2006 14:46:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fdti4-0000Os-7L for kitten@ietf.org; Wed, 10 May 2006 14:46:56 -0400 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fdti2-0003fA-Q1 for kitten@ietf.org; Wed, 10 May 2006 14:46:56 -0400 Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id k4AIkrrM019044 for ; Wed, 10 May 2006 11:46:54 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k4AIkSS7014000 for ; Wed, 10 May 2006 12:46: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 k4AIkrWP029767 for ; Wed, 10 May 2006 13:46:53 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k4AIkr4K029766 for kitten@ietf.org; Wed, 10 May 2006 13:46:53 -0500 (CDT) Date: Wed, 10 May 2006 13:46:53 -0500 From: Nicolas Williams To: kitten@ietf.org Message-ID: <20060510184652.GZ28647@binky.Central.Sun.COM> Mail-Followup-To: kitten@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: Subject: Updated I18N proposal 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 Offline Jeff Altman argues that the problem with my proposal is GSS_C_CES_*. So I offer, instead, this: - In the GSS-APIv3 deprecate (note that deprecate != remove): - GSS_Import_name() for any name type other than GSS_C_NT_EXPORTED_NAME - GSS_Display_name() - GSS_Display_status() - In the GSS-APIv3 add versions of the above functions that specify the use of Unicode in the abstract API, UTF-8 in the C bidnings, etc... - GSS_Import_name_unicode() (gss_import_name_utf8() in C bindings) - GSS_Display_name_unicode() (gss_display_name_utf8() in C bindings) - GSS_Display_status_unicode() (gss_display_status_utf8() in C bindings) - In the GSS-APIv3 add *optional* _utility_ function versions of the above that utilize the CES of the current locale: - GSS_Import_name_locale() (gss_import_name_locale()) - GSS_Display_name_locale() (gss_display_name_locale()) - GSS_Display_status_locale() (gss_display_status_locale()) Suitable warnings about the limited applicability of these functions and the limited portability of applications that rely on these interfaces will be included in the specs. - In the GSS-APIv2u2 add a note about implementation history of the Latin-1 requirements of the GSS-APIv2u1, but otherwise change nothing. Though we may want to add the above to the GSS-APIv2u2 as well; I see no reason not to. I believe this should make Jeff Altman happy (no GSS_C_CES_* symbols, values, no registry or reuse of existing registries), as well as Martin. It will certainly make me happy, and probably Jeff Hutzelman as well. Cheers, Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed May 10 15:22:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FduGl-0008Gm-0P; Wed, 10 May 2006 15:22:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FduGk-0008Gh-3Z for kitten@ietf.org; Wed, 10 May 2006 15:22:46 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FduGg-0004eR-Qs for kitten@ietf.org; Wed, 10 May 2006 15:22:46 -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 k4AJMOmL020922 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 10 May 2006 15:22:29 -0400 (EDT) Message-ID: <44623D70.8030501@columbia.edu> Date: Wed, 10 May 2006 15:22:24 -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: Michael B Allen References: <20060509231708.4ec70cc2.mba2000@ioplex.com> <200605101535.RAA28032@uw1048.wdf.sap.corp> <20060510123839.242e05b7.mba2000@ioplex.com> <44621DF0.3040205@columbia.edu> <20060510143109.4b45f7fe.mba2000@ioplex.com> In-Reply-To: <20060510143109.4b45f7fe.mba2000@ioplex.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: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: kitten@ietf.org, Nicolas.Williams@sun.com Subject: Re: I18N & L10N proposal for GSS-API (v2u2/v3) 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="===============0847197752==" Errors-To: kitten-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============0847197752== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080100000609010603070108" This is a cryptographically signed message in MIME format. --------------ms080100000609010603070108 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Michael B Allen wrote: > On Wed, 10 May 2006 13:08:00 -0400 > Jeffrey Altman wrote: > >> For GSS-APIv3 we can choose to do something different. What I am >> wondering is whether we need to define both a GSS-API and a GSS-SPI. >> The layer that implements both the GSS-API and the GSS-SPI would be >> responsible for handling translation from locale to UTF8 and mechanisms >> (which would only implement the GSS-SPI) would be required to handle >> UTF8 on their boundary. > > I see. So you're more concerned with mechglue mechanism > interoperability? Is SPI "service provider interface"? > > Mike SPI is "service provider interface". Deciding to standardize a API / SPI model would require that the IETF agree to standardize an ABI. This would be a huge departure from prior efforts and it would certainly go badly. As Jeffrey Hutzelman reminds us, the GSS-API is an API and the API is frequently implemented by the mechanisms themselves. I made the above comment in response to one of Martin's concerns which was the quantity of code that mechanisms implementing GSS-API would be required to implement. I too am concerned about arbitrary levels of character-set complexity being required of mechanisms. Not all operating systems on which GSS-API is implemented have a concept of locale. Others as Martin has pointed out do not have control over the character-set used by the end user. Martin's examples of 1993 HP-UX and Microsoft Windows have been disregarded by this audience but user's entering data into a web form which is later passed into GSS-API is a modern day example of the same problem. The user has a locale which is some Windows ANSI code page, the web server is running under ISO Latin-1. Now if the user's input is provided to gss_foo() and it is expected to be translated by GSS-API based upon the web server's locale, the translation is going to be wrong. The web server must take responsibility for performing the translation from the user's input locale to the web server's locale and therefore might as well convert to UTF8. I believe Nico's latest proposal is sufficient to reduce the burden required of mechanism implementers while still providing the tools necessary for applications that can benefit from a set of locale based functions. Jeffrey Altman --------------ms080100000609010603070108 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 DxcNMDYwNTEwMTkyMjI0WjAjBgkqhkiG9w0BCQQxFgQUzi0C/684Vf1EmQCIwo9wLNgawoMw UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw7NrDB6BgsqhkiG9w0B CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AgMOzawwDQYJKoZIhvcNAQEBBQAEggEAJt+yP+WRZEdYa222UGwX2zVG0KkVOaSBxeGzMwXc l0mIF2wn+FFSxG3Qtv/pYNNDzFdg9F1CjlKWjIZiw67oPlkUwtmryTp+ftjv6sUqWWnjkt3j vsFCScr1L7DabrLt54UQ6LZ+j837s1m4LcZ2hqp0EOQ5Z9zomcqwFTK9kqhMjMW6mCGMFUy6 pxg/ZLtV+jnNluAXrczOuOoFnRUbPjKnyN968GAITQKLEl3rtnc0O4x/TGaonxL0oY/9+mSI TzoaUBZsJiCXw39L/1OvBGFwxjBrwgc8Sb/P4bMUs8Tn3m/SpNBSK8ZqtkWwRmee+D/r4qLI VQqIT9gpalLE4AAAAAAAAA== --------------ms080100000609010603070108-- --===============0847197752== 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 --===============0847197752==-- From kitten-bounces@lists.ietf.org Wed May 10 15:31:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FduOq-0003Kl-VV; Wed, 10 May 2006 15:31:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FduOp-0003GA-Bz for kitten@ietf.org; Wed, 10 May 2006 15:31:07 -0400 Received: from li4-142.members.linode.com ([66.220.1.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FduOn-00055k-3N for kitten@ietf.org; Wed, 10 May 2006 15:31:07 -0400 Received: from quark.foo.net (c-69-142-196-170.hsd1.nj.comcast.net [69.142.196.170]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by li4-142.members.linode.com (Postfix) with ESMTP id 6F3FD42B83; Wed, 10 May 2006 15:31:03 -0400 (EDT) Date: Wed, 10 May 2006 15:28:42 -0400 From: Michael B Allen To: Jeffrey Hutzelman Message-Id: <20060510152842.7c2acef1.mba2000@ioplex.com> In-Reply-To: <16D248503761D077DBEF38AF@sirius.fac.cs.cmu.edu> References: <20060509231708.4ec70cc2.mba2000@ioplex.com> <200605101535.RAA28032@uw1048.wdf.sap.corp> <20060510123839.242e05b7.mba2000@ioplex.com> <16D248503761D077DBEF38AF@sirius.fac.cs.cmu.edu> X-Mailer: Sylpheed version 1.0.6 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.6 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: kitten@ietf.org, Nicolas.Williams@sun.com Subject: Re: I18N & L10N proposal for GSS-API (v2u2/v3) 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 Genereally I'm in your camp Jeff. Thanks for the summary. If you guys want a UTF-8 interface that's fine as long as I (and I think I speak for most if not all other developers) can ignore it. That's the only point I feel strongly about. As for using UTF-8 internally, that sounds like an implementation detail to me. Mike _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed May 10 16:18:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fdv8U-0004Kx-GA; Wed, 10 May 2006 16:18:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fdv8T-0004J0-VP for kitten@ietf.org; Wed, 10 May 2006 16:18:17 -0400 Received: from li4-142.members.linode.com ([66.220.1.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fdv8R-0007du-I5 for kitten@ietf.org; Wed, 10 May 2006 16:18:17 -0400 Received: from quark.foo.net (c-69-142-196-170.hsd1.nj.comcast.net [69.142.196.170]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by li4-142.members.linode.com (Postfix) with ESMTP id B6BA842B83; Wed, 10 May 2006 16:18:09 -0400 (EDT) Date: Wed, 10 May 2006 16:15:47 -0400 From: Michael B Allen To: Jeffrey Altman Message-Id: <20060510161547.52db2035.mba2000@ioplex.com> In-Reply-To: <44623D70.8030501@columbia.edu> References: <20060509231708.4ec70cc2.mba2000@ioplex.com> <200605101535.RAA28032@uw1048.wdf.sap.corp> <20060510123839.242e05b7.mba2000@ioplex.com> <44621DF0.3040205@columbia.edu> <20060510143109.4b45f7fe.mba2000@ioplex.com> <44623D70.8030501@columbia.edu> X-Mailer: Sylpheed version 1.0.6 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.6 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: kitten@ietf.org, Nicolas.Williams@sun.com Subject: Re: I18N & L10N proposal for GSS-API (v2u2/v3) 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, 10 May 2006 15:22:24 -0400 Jeffrey Altman wrote: > implement. I too am concerned about arbitrary levels of character-set > complexity being required of mechanisms. Not all operating systems > on which GSS-API is implemented have a concept of locale. Others as First, I regret saying "locale" because it's not like we're talking about formatting monitary units. Each environment has a premier string type and provides facilities for converted between that type and other encodings. If it does not have such a facility then that system isn't really a candidate for gssapi support in the first place. Second, it seems to me that using UTF-8 internally is an implementation detail and therefore I don't feel stongly about it. However, just in case this somehow percolates up into developer space I just want to say that I think it is *more* complex because in the non-UTF-8 case (which is really all we're worried about) you're converting twice instead of once (e.g. you could end up doing Latin1 <-> UTF-8 <-> ISO-8859-4). I do acknowledge that there is an advantage to using UTF-8 for complex string processing. If you're searching for an '@' sign in a string, with UTF-8 you can use traditional strchr or *ch == '@' style code. Under my proprosal the C implementation *might* be complicated with code to extract each character with a routine like mbrtowc(3) and then compare with something like wch == L'@'. But virtually 99% of that type of processing occurs within the mechanism implementations which again seems to me like an implementation specific detail. And thus mandating UTF-8 at mech boundries doesn't make sense to me. > .... but user's entering data into > a web form which is later passed into GSS-API is a modern day example > of the same problem. The user has a locale which is some Windows ANSI > code page, the web server is running under ISO Latin-1. Now if the > user's input is provided to gss_foo() and it is expected to be > translated by GSS-API based upon the web server's locale, the > translation is going to be wrong. The web server must take > responsibility for performing the translation from the user's input > locale to the web server's locale and therefore might as well convert > to UTF8. This is such an extreme example it's a red herring. Web servers provide facilities for dealing with the different locales of clients. That is clearly the responsibility of the web server and not of libraries used by it. Mike _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed May 10 16:19:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fdv9l-00069a-QA; Wed, 10 May 2006 16:19:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fdv9k-00069V-LB for kitten@lists.ietf.org; Wed, 10 May 2006 16:19:36 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fdv9k-0007gV-E4 for kitten@lists.ietf.org; Wed, 10 May 2006 16:19:36 -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 k4AKJZmi003648 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 10 May 2006 16:19:36 -0400 (EDT) Message-ID: <44624AD8.7000207@columbia.edu> Date: Wed, 10 May 2006 16:19:36 -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 CC: kitten@lists.ietf.org References: <4446B039.9000806@columbia.edu> In-Reply-To: <4446B039.9000806@columbia.edu> 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: 5ebbf074524e58e662bc8209a6235027 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: , Content-Type: multipart/mixed; boundary="===============0033470810==" Errors-To: kitten-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============0033470810== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010905070301070904040003" This is a cryptographically signed message in MIME format. --------------ms010905070301070904040003 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The document "Desired Enhancements to GSSAPI Naming" has passed the Working Group Last Call and will be forwarded to the IESG. During the last call period a discussion of the need to address internationalization issues was raised. The rough consensus of the working group is that internationalization is an issue related to but separate from naming that can be addressed independently. Active discussions in the working group are on-going with regards to this topic. Jeffrey Altman 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 > > 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 > > > ------------------------------------------------------------------------ > > _______________________________________________ > Kitten mailing list > Kitten@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/kitten --------------ms010905070301070904040003 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 DxcNMDYwNTEwMjAxOTM2WjAjBgkqhkiG9w0BCQQxFgQU26zkSZGtBdEWWB0JgNNyQ7h5f1Qw UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw7NrDB6BgsqhkiG9w0B CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AgMOzawwDQYJKoZIhvcNAQEBBQAEggEAeTgceoKUUcgfewvU5k2r5UA4uScpzOOuEaPCP7kH jngGW73Y4SOwdxkpVII7W/awp+K19vNQwR7WiTqty1/APpKHkDFBAhtvrnnHJO5fXDAxbDMZ eBbb2yPfHUZSoZPJLgChRK3cyJ3QoM7nNvs9HZFmXcES4uYXL6ufM3T0jCemyZIsEg8L7ZL1 qtMRbSkiR2Mvaulhk1omZSJt1rL4AZ6AgQtliW4yYii0ZJuM/JsBdAB2FwntwR99fTQPx+vP 5zlKXAr+P6lFKU5JZs0MRagtbcYtZasVETw1Dx1Ty62hn/V6f5gliU1gcHe5PQ+WmF3bjdk6 KTMj/jkG5X5VggAAAAAAAA== --------------ms010905070301070904040003-- --===============0033470810== 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 --===============0033470810==-- From kitten-bounces@lists.ietf.org Wed May 10 16:35:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdvPD-0006HL-Fq; Wed, 10 May 2006 16:35:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdvPC-0006HB-A2 for kitten@ietf.org; Wed, 10 May 2006 16:35:34 -0400 Received: from li4-142.members.linode.com ([66.220.1.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdvPB-0008Sz-0a for kitten@ietf.org; Wed, 10 May 2006 16:35:34 -0400 Received: from quark.foo.net (c-69-142-196-170.hsd1.nj.comcast.net [69.142.196.170]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by li4-142.members.linode.com (Postfix) with ESMTP id E740E42B83; Wed, 10 May 2006 16:35:31 -0400 (EDT) Date: Wed, 10 May 2006 16:33:10 -0400 From: Michael B Allen To: Nicolas Williams Message-Id: <20060510163310.1341d444.mba2000@ioplex.com> In-Reply-To: <20060510184652.GZ28647@binky.Central.Sun.COM> References: <20060510184652.GZ28647@binky.Central.Sun.COM> X-Mailer: Sylpheed version 1.0.6 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.6 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: kitten@ietf.org Subject: Re: Updated I18N proposal 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, 10 May 2006 13:46:53 -0500 Nicolas Williams wrote: > - In the GSS-APIv3 deprecate (note that deprecate != remove): > > - GSS_Import_name() for any name type other than GSS_C_NT_EXPORTED_NAME > - GSS_Display_name() > - GSS_Display_status() > > > - In the GSS-APIv3 add *optional* _utility_ function versions of the > above that utilize the CES of the current locale: > > - GSS_Import_name_locale() (gss_import_name_locale()) > - GSS_Display_name_locale() (gss_display_name_locale()) > - GSS_Display_status_locale() (gss_display_status_locale()) Why not do: > - GSS_Import_name_latin1() (gss_import_name_latin1()) > - GSS_Display_name_latin1() (gss_display_name_latin1()) > - GSS_Display_status_latin1() (gss_display_status_latin1()) and leave the original functions alone but simply remove the "latin1" requirement? That's basically how most implementations work now so you're just aligning the spec with reality. Yes, I know for C implementations "just-use-8" behavior will not be to spec but it wasn't before. Then implementations can slowly add the necessary conversions fix things as bugs pop up in existing code. Mike _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed May 10 16:39:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdvT4-0006bJ-5w; Wed, 10 May 2006 16:39:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdvT2-0006al-Sc for kitten@ietf.org; Wed, 10 May 2006 16:39:32 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdvT1-0000Hp-Au for kitten@ietf.org; Wed, 10 May 2006 16:39:32 -0400 Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id k4AKdSxW012015 for ; Wed, 10 May 2006 14:39:28 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k4AKd3ds028156 for ; Wed, 10 May 2006 14:39:04 -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 k4AKdSih029934; Wed, 10 May 2006 15:39:28 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k4AKdRrR029933; Wed, 10 May 2006 15:39:27 -0500 (CDT) Date: Wed, 10 May 2006 15:39:27 -0500 From: Nicolas Williams To: Michael B Allen Message-ID: <20060510203927.GD28647@binky.Central.Sun.COM> Mail-Followup-To: Michael B Allen , kitten@ietf.org References: <20060510184652.GZ28647@binky.Central.Sun.COM> <20060510163310.1341d444.mba2000@ioplex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060510163310.1341d444.mba2000@ioplex.com> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: kitten@ietf.org Subject: Re: Updated I18N proposal 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, May 10, 2006 at 04:33:10PM -0400, Michael B Allen wrote: > On Wed, 10 May 2006 13:46:53 -0500 > Nicolas Williams wrote: > > > - In the GSS-APIv3 deprecate (note that deprecate != remove): > > > > - GSS_Import_name() for any name type other than GSS_C_NT_EXPORTED_NAME > > - GSS_Display_name() > > - GSS_Display_status() > > > > > > - In the GSS-APIv3 add *optional* _utility_ function versions of the > > above that utilize the CES of the current locale: > > > > - GSS_Import_name_locale() (gss_import_name_locale()) > > - GSS_Display_name_locale() (gss_display_name_locale()) > > - GSS_Display_status_locale() (gss_display_status_locale()) > > Why not do: > > > - GSS_Import_name_latin1() (gss_import_name_latin1()) > > - GSS_Display_name_latin1() (gss_display_name_latin1()) > > - GSS_Display_status_latin1() (gss_display_status_latin1()) I wouldn't oppose _latin1() versions of these functions as long as they're optional, and if they were likely to be useful, but methinks they'd not be useful. > and leave the original functions alone but simply remove the "latin1" > requirement? That's basically how most implementations work now so you're > just aligning the spec with reality. Yes, I know for C implementations > "just-use-8" behavior will not be to spec but it wasn't before. Then > implementations can slowly add the necessary conversions fix things as > bugs pop up in existing code. The originals have been implemented both ways: just-use-locale's-codeset and Latin-1. Leaving them alone is not an option since some implementations would be left with no standards compliant way to do what they do without also modifying applications to do what the _locale() utility functions would do anyways. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed May 10 17:08:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fdvub-0005eZ-Px; Wed, 10 May 2006 17:08:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdvuZ-0005eU-Uj for kitten@ietf.org; Wed, 10 May 2006 17:07:59 -0400 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdvuY-0001K4-JA for kitten@ietf.org; Wed, 10 May 2006 17:07:59 -0400 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id XAA17197; Wed, 10 May 2006 23:07:54 +0200 (MESZ) From: Martin Rex Message-Id: <200605102107.XAA05755@uw1048.wdf.sap.corp> To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Wed, 10 May 2006 23:07:53 +0200 (MET DST) In-Reply-To: <20060510184652.GZ28647@binky.Central.Sun.COM> from "Nicolas Williams" at May 10, 6 01:46:53 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: a7d6aff76b15f3f56fcb94490e1052e4 Cc: kitten@ietf.org Subject: Re: Updated I18N proposal 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 Nico, I like your updated proposal. Nicolas Williams wrote: > > So I offer, instead, this: > > - In the GSS-APIv3 deprecate (note that deprecate != remove): > > - GSS_Import_name() for any name type other than GSS_C_NT_EXPORTED_NAME > - GSS_Display_name() > - GSS_Display_status() + retain the current behaviour of existing implementations, but check out and non-ambiguously document what it **really** does! > > - In the GSS-APIv3 add versions of the above functions that specify the > use of Unicode in the abstract API, UTF-8 in the C bindings, etc... > > - GSS_Import_name_unicode() (gss_import_name_utf8() in C bindings) > - GSS_Display_name_unicode() (gss_display_name_utf8() in C bindings) > - GSS_Display_status_unicode() (gss_display_status_utf8() in C bindings) I appreciate that. :) > > - In the GSS-APIv3 add *optional* _utility_ function versions of the > above that utilize the CES of the current locale: > > - GSS_Import_name_locale() (gss_import_name_locale()) > - GSS_Display_name_locale() (gss_display_name_locale()) > - GSS_Display_status_locale() (gss_display_status_locale()) I know little about Java. Is there something like "locale" on Java -- I mean at the GSS-API level? There may be something when calling to the native code interface, but I'm really wondering whether this applies to the Java GSS-API bindings. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed May 10 17:11:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fdvxj-0005mU-Ap; Wed, 10 May 2006 17:11:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fdvxi-0005mP-Er for kitten@ietf.org; Wed, 10 May 2006 17:11:14 -0400 Received: from li4-142.members.linode.com ([66.220.1.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fdvxh-0001Wl-65 for kitten@ietf.org; Wed, 10 May 2006 17:11:14 -0400 Received: from quark.foo.net (c-69-142-196-170.hsd1.nj.comcast.net [69.142.196.170]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by li4-142.members.linode.com (Postfix) with ESMTP id EF1CB42B83; Wed, 10 May 2006 17:11:11 -0400 (EDT) Date: Wed, 10 May 2006 17:08:50 -0400 From: Michael B Allen To: Nicolas Williams Message-Id: <20060510170850.374134bc.mba2000@ioplex.com> In-Reply-To: <20060510203927.GD28647@binky.Central.Sun.COM> References: <20060510184652.GZ28647@binky.Central.Sun.COM> <20060510163310.1341d444.mba2000@ioplex.com> <20060510203927.GD28647@binky.Central.Sun.COM> X-Mailer: Sylpheed version 1.0.6 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.6 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: kitten@ietf.org Subject: Re: Updated I18N proposal 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, 10 May 2006 15:39:27 -0500 Nicolas Williams wrote: > > > - GSS_Import_name_latin1() (gss_import_name_latin1()) > > > - GSS_Display_name_latin1() (gss_display_name_latin1()) > > > - GSS_Display_status_latin1() (gss_display_status_latin1()) > > I wouldn't oppose _latin1() versions of these functions as long as > they're optional, and if they were likely to be useful, but methinks > they'd not be useful. You're right. I don't know what I was thinking. > > and leave the original functions alone but simply remove the "latin1" > > requirement? That's basically how most implementations work now so you're > > just aligning the spec with reality. Yes, I know for C implementations > > "just-use-8" behavior will not be to spec but it wasn't before. Then > > implementations can slowly add the necessary conversions fix things as > > bugs pop up in existing code. > > The originals have been implemented both ways: just-use-locale's-codeset > and Latin-1. Leaving them alone is not an option since some > implementations would be left with no standards compliant way to do what > they do without also modifying applications to do what the _locale() > utility functions would do anyways. But implementations of these functions never followed the spec in the first place. What about all the existing code that uses gss_display_name? As mechs start to use extended charsets more and more the old code will start to break. It's a lot easier to fix libgssapi as opposed to running around adding "_locale" to all your code. In fact, I'll make a bold prediction - implementors will make gss_import_name and gss_import_name_locale behave exactly the same. Mike _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed May 10 17:19:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fdw5M-0007TN-4Z; Wed, 10 May 2006 17:19:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fdw5L-0007TI-Fv for kitten@ietf.org; Wed, 10 May 2006 17:19:07 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fdw5K-0001kN-5u for kitten@ietf.org; Wed, 10 May 2006 17:19:07 -0400 Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id k4ALJ5Ke006734 for ; Wed, 10 May 2006 15:19:05 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k4ALIe63019309 for ; Wed, 10 May 2006 15:18: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 k4ALJ4FJ029990; Wed, 10 May 2006 16:19:04 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k4ALJ4rN029989; Wed, 10 May 2006 16:19:04 -0500 (CDT) Date: Wed, 10 May 2006 16:19:04 -0500 From: Nicolas Williams To: Martin Rex Message-ID: <20060510211904.GG28647@binky.Central.Sun.COM> Mail-Followup-To: Martin Rex , kitten@ietf.org References: <20060510184652.GZ28647@binky.Central.Sun.COM> <200605102107.XAA05755@uw1048.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200605102107.XAA05755@uw1048.wdf.sap.corp> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: kitten@ietf.org Subject: Re: Updated I18N proposal 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, May 10, 2006 at 11:07:53PM +0200, Martin Rex wrote: > Nico, > > I like your updated proposal. Excellent. We're close to consensus then. Expect an I-D soon, and a respin of my expired I-Ds. > Nicolas Williams wrote: > > > > So I offer, instead, this: > > > > - In the GSS-APIv3 deprecate (note that deprecate != remove): > > > > - GSS_Import_name() for any name type other than GSS_C_NT_EXPORTED_NAME > > - GSS_Display_name() > > - GSS_Display_status() > > + retain the current behaviour of existing implementations, Oh, I expect that existing implementations will do what they do. > but check out and non-ambiguously document what it **really** does! In the IETF document? I suppose we could, though maybe not exhaustively. > > > > - In the GSS-APIv3 add versions of the above functions that specify the > > use of Unicode in the abstract API, UTF-8 in the C bindings, etc... > > > > - GSS_Import_name_unicode() (gss_import_name_utf8() in C bindings) > > - GSS_Display_name_unicode() (gss_display_name_utf8() in C bindings) > > - GSS_Display_status_unicode() (gss_display_status_utf8() in C bindings) > > I appreciate that. :) > > > > > - In the GSS-APIv3 add *optional* _utility_ function versions of the > > above that utilize the CES of the current locale: > > > > - GSS_Import_name_locale() (gss_import_name_locale()) > > - GSS_Display_name_locale() (gss_display_name_locale()) > > - GSS_Display_status_locale() (gss_display_status_locale()) > > I know little about Java. > Is there something like "locale" on Java -- I mean at the GSS-API level? > There may be something when calling to the native code interface, > but I'm really wondering whether this applies to the Java GSS-API bindings. I was hoping to leave the Java bindings to Java experts, but I can research this and get back to you. The point of saying "unicode" in the abstract API is to leave the actual details to the bindings -- some might use UTF-16, etc... (some languages might not support anything other than, say, US-ASCII, whatever). Note also that I don't want to require Unicode 4.x, or 3.x or any particular version, planes, etcetera in the abstract API. Why? Because some language bindings that may be limited to UCS-2 may not be able to comply. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed May 10 17:20:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fdw6G-0000Za-DQ; Wed, 10 May 2006 17:20:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fdw6E-0000XD-TV for kitten@ietf.org; Wed, 10 May 2006 17:20:02 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fdw6D-0001mT-N2 for kitten@ietf.org; Wed, 10 May 2006 17:20:02 -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 serrano.cc.columbia.edu (8.13.6/8.13.6) with ESMTP id k4ALJu1E016789 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 10 May 2006 17:19:56 -0400 (EDT) Message-ID: <44625900.9030802@columbia.edu> Date: Wed, 10 May 2006 17:20:00 -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@sap.com References: <200605102107.XAA05755@uw1048.wdf.sap.corp> In-Reply-To: <200605102107.XAA05755@uw1048.wdf.sap.corp> X-Enigmail-Version: 0.94.0.0 X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: kitten@ietf.org, Nicolas Williams Subject: Re: Updated I18N proposal 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="===============2084166862==" Errors-To: kitten-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============2084166862== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090805030101040203060808" This is a cryptographically signed message in MIME format. --------------ms090805030101040203060808 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Martin Rex wrote: >> - In the GSS-APIv3 add *optional* _utility_ function versions of the >> above that utilize the CES of the current locale: >> >> - GSS_Import_name_locale() (gss_import_name_locale()) >> - GSS_Display_name_locale() (gss_display_name_locale()) >> - GSS_Display_status_locale() (gss_display_status_locale()) > > I know little about Java. > Is there something like "locale" on Java -- I mean at the GSS-API level? > There may be something when calling to the native code interface, > but I'm really wondering whether this applies to the Java GSS-API bindings. I do not believe these will be implemented in the Java Bindings. Java uses UCS2 Unicode character representation. When calling out to a native GSS-API mechanism it will want to use the gss_xxx_unicode() versions. Same for C#. Jeffrey Altman --------------ms090805030101040203060808 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 DxcNMDYwNTEwMjEyMDAwWjAjBgkqhkiG9w0BCQQxFgQU4DNuhb5BvWqsYAwPea3TgLCKBZMw UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw7NrDB6BgsqhkiG9w0B CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AgMOzawwDQYJKoZIhvcNAQEBBQAEggEAobYyXNgcp1Cq8ajeKnn0UQxsQAhSjOnrXGS2sqUm U/pMJCrKBBvXV26v5LMqYVOG1B7m9u+uTx38Mv3QrKtzrR/NpTCGkUYHqC0zZZ2H1q2jZbmE 2L/PEtGe/YuFlS2JlqgR8rGRfPCNxvLQWu7fgUVN4Im/dc21bkD5yJwywFjcjQGZDuMDhfSw /QlSWUnxy5YCRsHoposdJeYcq855zPoKZk78jSPecB2ESYzuCyLSk/L0T8r+A31K9T12hDx8 KtfYt2CSBif1Ju4L391tPI0FjyBBcdd0VJEolky6OU5EnAd0FWXPXag/ITNXoZHLFPTogYdg B1gIuVY9d8KtKAAAAAAAAA== --------------ms090805030101040203060808-- --===============2084166862== 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 --===============2084166862==-- From kitten-bounces@lists.ietf.org Wed May 10 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 1Fdw6Z-0000sW-Ix; Wed, 10 May 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 1Fdw6Y-0000rf-3x for kitten@ietf.org; Wed, 10 May 2006 17:20:22 -0400 Received: from nwkea-mail-4.sun.com ([192.18.42.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fdw6W-0001mv-MW for kitten@ietf.org; Wed, 10 May 2006 17:20:22 -0400 Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by nwkea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id k4ALKJUm021980 for ; Wed, 10 May 2006 14:20:19 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k4ALJsIw019883 for ; Wed, 10 May 2006 15:19:54 -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 k4ALKJKC029997; Wed, 10 May 2006 16:20:19 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k4ALKJsn029996; Wed, 10 May 2006 16:20:19 -0500 (CDT) Date: Wed, 10 May 2006 16:20:19 -0500 From: Nicolas Williams To: Michael B Allen Message-ID: <20060510212019.GH28647@binky.Central.Sun.COM> Mail-Followup-To: Michael B Allen , kitten@ietf.org References: <20060510184652.GZ28647@binky.Central.Sun.COM> <20060510163310.1341d444.mba2000@ioplex.com> <20060510203927.GD28647@binky.Central.Sun.COM> <20060510170850.374134bc.mba2000@ioplex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060510170850.374134bc.mba2000@ioplex.com> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: kitten@ietf.org Subject: Re: Updated I18N proposal 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, May 10, 2006 at 05:08:50PM -0400, Michael B Allen wrote: > What about all the existing code that uses gss_display_name? As > mechs start to use extended charsets more and more the old code > will start to break. It's a lot easier to fix libgssapi as opposed > to running around adding "_locale" to all your code. In fact, I'll > make a bold prediction - implementors will make gss_import_name and > gss_import_name_locale behave exactly the same. Existing implementations can't be required to be made to comply with the original spec. Running code will keep running. Code that doesn't run will continue to not run. End of story :) _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed May 10 18:14:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdwxE-0003rY-Gf; Wed, 10 May 2006 18:14:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdwxD-0003rT-8H for kitten@ietf.org; Wed, 10 May 2006 18:14:47 -0400 Received: from li4-142.members.linode.com ([66.220.1.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fdwx9-00049O-Va for kitten@ietf.org; Wed, 10 May 2006 18:14:47 -0400 Received: from quark.foo.net (c-69-142-196-170.hsd1.nj.comcast.net [69.142.196.170]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by li4-142.members.linode.com (Postfix) with ESMTP id 5DA6542B83; Wed, 10 May 2006 18:14:36 -0400 (EDT) Date: Wed, 10 May 2006 18:12:14 -0400 From: Michael B Allen To: Nicolas Williams Message-Id: <20060510181214.2ebd041c.mba2000@ioplex.com> In-Reply-To: <20060510212019.GH28647@binky.Central.Sun.COM> References: <20060510184652.GZ28647@binky.Central.Sun.COM> <20060510163310.1341d444.mba2000@ioplex.com> <20060510203927.GD28647@binky.Central.Sun.COM> <20060510170850.374134bc.mba2000@ioplex.com> <20060510212019.GH28647@binky.Central.Sun.COM> X-Mailer: Sylpheed version 1.0.6 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.6 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: kitten@ietf.org Subject: Re: Updated I18N proposal 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, 10 May 2006 16:20:19 -0500 Nicolas Williams wrote: > On Wed, May 10, 2006 at 05:08:50PM -0400, Michael B Allen wrote: > > What about all the existing code that uses gss_display_name? As > > mechs start to use extended charsets more and more the old code > > will start to break. It's a lot easier to fix libgssapi as opposed > > to running around adding "_locale" to all your code. In fact, I'll > > make a bold prediction - implementors will make gss_import_name and > > gss_import_name_locale behave exactly the same. > > Existing implementations can't be required to be made to comply with the > original spec. Running code will keep running. Code that doesn't run > will continue to not run. End of story :) If gss_display_name is supposed to maintain just-use-8 behavior and someone now starts using a Cyrillic character in their username what is the implementation supposed to do? _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed May 10 18:29:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdxAy-000754-Gv; Wed, 10 May 2006 18:29:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdxAx-00074z-UU for kitten@ietf.org; Wed, 10 May 2006 18:28:59 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdxAw-0004rx-HJ for kitten@ietf.org; Wed, 10 May 2006 18:28:59 -0400 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id k4AMSwKe013879 for ; Wed, 10 May 2006 16:28:58 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k4AMSvQt017403 for ; Wed, 10 May 2006 16:28:58 -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 k4AMSvb7000145; Wed, 10 May 2006 17:28:57 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k4AMSvee000144; Wed, 10 May 2006 17:28:57 -0500 (CDT) Date: Wed, 10 May 2006 17:28:57 -0500 From: Nicolas Williams To: Michael B Allen Message-ID: <20060510222856.GK28647@binky.Central.Sun.COM> Mail-Followup-To: Michael B Allen , kitten@ietf.org References: <20060510184652.GZ28647@binky.Central.Sun.COM> <20060510163310.1341d444.mba2000@ioplex.com> <20060510203927.GD28647@binky.Central.Sun.COM> <20060510170850.374134bc.mba2000@ioplex.com> <20060510212019.GH28647@binky.Central.Sun.COM> <20060510181214.2ebd041c.mba2000@ioplex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060510181214.2ebd041c.mba2000@ioplex.com> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: kitten@ietf.org Subject: Re: Updated I18N proposal 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, May 10, 2006 at 06:12:14PM -0400, Michael B Allen wrote: > On Wed, 10 May 2006 16:20:19 -0500 > Nicolas Williams wrote: > > > On Wed, May 10, 2006 at 05:08:50PM -0400, Michael B Allen wrote: > > > What about all the existing code that uses gss_display_name? As > > > mechs start to use extended charsets more and more the old code > > > will start to break. It's a lot easier to fix libgssapi as opposed > > > to running around adding "_locale" to all your code. In fact, I'll > > > make a bold prediction - implementors will make gss_import_name and > > > gss_import_name_locale behave exactly the same. > > > > Existing implementations can't be required to be made to comply with the > > original spec. Running code will keep running. Code that doesn't run > > will continue to not run. End of story :) > > If gss_display_name is supposed to maintain just-use-8 behavior and Whatever was implemented. Martin has an implementation that does what RFC2743 said to do. > someone now starts using a Cyrillic character in their username what is > the implementation supposed to do? Whatever it does now. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed May 10 18:50:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdxVl-0004dx-M6; Wed, 10 May 2006 18:50:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdxVk-0004ds-OL for kitten@ietf.org; Wed, 10 May 2006 18:50:28 -0400 Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdxVj-0005yG-Ck for kitten@ietf.org; Wed, 10 May 2006 18:50:28 -0400 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id AAA12216; Thu, 11 May 2006 00:50:23 +0200 (MESZ) From: Martin Rex Message-Id: <200605102250.AAA08063@uw1048.wdf.sap.corp> To: mba2000@ioplex.com (Michael B Allen) Date: Thu, 11 May 2006 00:50:23 +0200 (MET DST) In-Reply-To: <20060510181214.2ebd041c.mba2000@ioplex.com> from "Michael B Allen" at May 10, 6 06:12:14 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: d6b246023072368de71562c0ab503126 Cc: kitten@ietf.org Subject: Re: Updated I18N proposal 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 Michael B Allen wrote: > > If gss_display_name is supposed to maintain just-use-8 behavior and > someone now starts using a Cyrillic character in their username what is > the implementation supposed to do? When the term "just-use-8" was being used to describe the "encoding" of Kerberos principals in rfc1510 implementations, it meant that integers in the range 0 to 127 were considered to be 7-Bit ASCII characters while integers in the range -128 to -1 (or 128 to 255) were treated as mere integers. There is no such thing as a cyrillic character for a "just-use-8" gssapi mechanism implementation. *Applications* may interpret certain integers outside of 7-bit US-ASCII as cyrillic characters (or more precisely, users might perceive those integers as as cyrillic characters based on the font that is used for visualization and/or the keyboard driver in use). -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu May 11 09:37:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeBLb-0007TQ-9z; Thu, 11 May 2006 09:36:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeBLa-0007TL-Iy for kitten@ietf.org; Thu, 11 May 2006 09:36:54 -0400 Received: from chokecherry.srv.cs.cmu.edu ([128.2.185.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeBLY-00024e-BF for kitten@ietf.org; Thu, 11 May 2006 09:36:54 -0400 Received: from mariner.pc.cs.cmu.edu (MARINER.PC.CS.CMU.EDU [128.2.200.130]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.5/8.13.5) with ESMTP id k4BDak0L002106 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 11 May 2006 09:36:46 -0400 (EDT) Date: Thu, 11 May 2006 09:36:45 -0400 From: Jeffrey Hutzelman To: Jeffrey Altman , martin.rex@sap.com Message-ID: <400C9EE87772E2BFD8E3D18D@mariner.pc.cs.cmu.edu> In-Reply-To: <44625900.9030802@columbia.edu> References: <200605102107.XAA05755@uw1048.wdf.sap.corp> <44625900.9030802@columbia.edu> Originator-Info: login-token=Mulberry:01PNlJc6ZBvueIJMH0b1d54tNLgJ7DDcKpTnfYclk=; 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: 50a516d93fd399dc60588708fd9a3002 Cc: kitten@ietf.org, Nicolas Williams Subject: Re: Updated I18N proposal 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, May 10, 2006 05:20:00 PM -0400 Jeffrey Altman wrote: > Martin Rex wrote: > >>> - In the GSS-APIv3 add *optional* _utility_ function versions of the >>> above that utilize the CES of the current locale: >>> >>> - GSS_Import_name_locale() (gss_import_name_locale()) >>> - GSS_Display_name_locale() (gss_display_name_locale()) >>> - GSS_Display_status_locale() (gss_display_status_locale()) >> >> I know little about Java. >> Is there something like "locale" on Java -- I mean at the GSS-API level? >> There may be something when calling to the native code interface, >> but I'm really wondering whether this applies to the Java GSS-API >> bindings. > > I do not believe these will be implemented in the Java Bindings. > Java uses UCS2 Unicode character representation. When calling out > to a native GSS-API mechanism it will want to use the gss_xxx_unicode() > versions. Same for C#. In fact, now that I think about it, we need to be a little careful here. The GSS-API has generally been defined as an abstract API plus language bindings for one or more languages. There are protocol specifications written in terms of the abstract API, and I expect there will be more in the future. We _don't_ want to get into a situation where protocols are specifying the use of GSS_Import_name_unicode() or GSS_Import_name_locale() explicitly -- that choice should be up to the needs of the application implementor. I think that at the abstract API level, we get to hand-wave away the charset issue, as long as we make sure it is dealt with appropriately in the concrete language bindings. So, Nico's proposal applies to the C language bindings, but not to C# or Java, and not to the abstract API. One thing we do need to do is _remove_ the Latin-1 requirement from the abstract API, where it doesn't belong, and push it down to the C-language bindings. There is still the question of when the *_locale versions must be implemented, and what charsets are required under what conditions. My previous proposal in this area is still relevant, and I have seen neither comments on that nor alternate proposals. -- Jeff _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu May 11 10:22:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeC3q-0004DV-LX; Thu, 11 May 2006 10:22:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeC3p-0004DP-OT for kitten@ietf.org; Thu, 11 May 2006 10:22:37 -0400 Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeC3o-0003ei-D9 for kitten@ietf.org; Thu, 11 May 2006 10:22:37 -0400 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id QAA00493; Thu, 11 May 2006 16:22:23 +0200 (MESZ) From: Martin Rex Message-Id: <200605111415.QAA18032@uw1048.wdf.sap.corp> To: jhutz@cmu.edu (Jeffrey Hutzelman) Date: Thu, 11 May 2006 16:15:21 +0200 (MET DST) In-Reply-To: <400C9EE87772E2BFD8E3D18D@mariner.pc.cs.cmu.edu> from "Jeffrey Hutzelman" at May 11, 6 09:36:45 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: 798b2e660f1819ae38035ac1d8d5e3ab Cc: kitten@ietf.org, Nicolas.Williams@sun.com, jhutz@cmu.edu Subject: Re: Updated I18N proposal 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: > > I think that at the abstract API level, we get to hand-wave away the > charset issue, as long as we make sure it is dealt with appropriately in > the concrete language bindings. So, Nico's proposal applies to the C > language bindings, but not to C# or Java, and not to the abstract API. I also think we need not and should not touch the Astract / high-level API specification, only the language bindings -- here the C-Bindings (rfc-2744) > > One thing we do need to do is _remove_ the Latin-1 requirement from the > abstract API, where it doesn't belong, and push it down to the C-language > bindings. There is no reference to Latin-1 at the abstract API today, and I believe there never was. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu May 11 10:54:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeCY5-0002RC-0x; Thu, 11 May 2006 10:53:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeCY4-0002R7-H1 for kitten@ietf.org; Thu, 11 May 2006 10:53:52 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeCY2-0005Op-Vv for kitten@ietf.org; Thu, 11 May 2006 10:53:52 -0400 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id k4BEroKe011967 for ; Thu, 11 May 2006 08:53:50 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k4BErngi005298 for ; Thu, 11 May 2006 08:53:50 -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 k4BErnbb000868; Thu, 11 May 2006 09:53:49 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k4BErlq3000867; Thu, 11 May 2006 09:53:47 -0500 (CDT) Date: Thu, 11 May 2006 09:53:47 -0500 From: Nicolas Williams To: Jeffrey Hutzelman Message-ID: <20060511145346.GR28647@binky.Central.Sun.COM> Mail-Followup-To: Jeffrey Hutzelman , Jeffrey Altman , martin.rex@sap.com, kitten@ietf.org References: <200605102107.XAA05755@uw1048.wdf.sap.corp> <44625900.9030802@columbia.edu> <400C9EE87772E2BFD8E3D18D@mariner.pc.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <400C9EE87772E2BFD8E3D18D@mariner.pc.cs.cmu.edu> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: kitten@ietf.org Subject: Re: Updated I18N proposal 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, May 11, 2006 at 09:36:45AM -0400, Jeffrey Hutzelman wrote: > I think that at the abstract API level, we get to hand-wave away the > charset issue, as long as we make sure it is dealt with appropriately in > the concrete language bindings. So, Nico's proposal applies to the C > language bindings, but not to C# or Java, and not to the abstract API. One > thing we do need to do is _remove_ the Latin-1 requirement from the > abstract API, where it doesn't belong, and push it down to the C-language > bindings. I agree! The abstract API spec should say something about I18N though, something that amounts to saying that language bindings authors need to take care of it, possibly recommending the use of Unicode. > There is still the question of when the *_locale versions must be > implemented, and what charsets are required under what conditions. My > previous proposal in this area is still relevant, and I have seen neither > comments on that nor alternate proposals. I think they must be present but may return an error if not implemented. Of course, why not implement them on any platforms that have non-UTF-8 locales? Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu May 11 10:57:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeCbu-0003wR-B2; Thu, 11 May 2006 10:57:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeCbt-0003wM-9s for kitten@ietf.org; Thu, 11 May 2006 10:57:49 -0400 Received: from biscayne-one-station.mit.edu ([18.7.7.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeCbr-0005XD-19 for kitten@ietf.org; Thu, 11 May 2006 10:57:49 -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 k4BEvfwR007526; Thu, 11 May 2006 10:57:41 -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 k4BEvWcX011442 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Thu, 11 May 2006 10:57:34 -0400 (EDT) In-Reply-To: <400C9EE87772E2BFD8E3D18D@mariner.pc.cs.cmu.edu> References: <200605102107.XAA05755@uw1048.wdf.sap.corp> <44625900.9030802@columbia.edu> <400C9EE87772E2BFD8E3D18D@mariner.pc.cs.cmu.edu> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <27614550-56B9-42CC-883C-AB2590C52F18@mit.edu> From: Ken Raeburn Date: Thu, 11 May 2006 10:57:31 -0400 To: Jeffrey Hutzelman 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: 7d33c50f3756db14428398e2bdedd581 Cc: kitten@ietf.org, Nicolas Williams Subject: Re: Updated I18N proposal 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 May 11, 2006, at 09:36, Jeffrey Hutzelman wrote: > On Wednesday, May 10, 2006 05:20:00 PM -0400 Jeffrey Altman > wrote: >> I do not believe these will be implemented in the Java Bindings. >> Java uses UCS2 Unicode character representation. When calling out >> to a native GSS-API mechanism it will want to use the >> gss_xxx_unicode() >> versions. Same for C#. Then the Java/C# bindings probably need to have a defined mechanism for handling received names outside the BMP. (Raise an exception?) > I think that at the abstract API level, we get to hand-wave away > the charset issue, as long as we make sure it is dealt with > appropriately in the concrete language bindings. So, Nico's > proposal applies to the C language bindings, but not to C# or Java, > and not to the abstract API. I agree. Ken _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu May 11 11:17:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeCv9-0005wQ-Ck; Thu, 11 May 2006 11:17:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeCv7-0005wL-AR for kitten@ietf.org; Thu, 11 May 2006 11:17:41 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeCv6-0006Hu-4b for kitten@ietf.org; Thu, 11 May 2006 11:17:41 -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 serrano.cc.columbia.edu (8.13.6/8.13.6) with ESMTP id k4BFHc7t016797 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 11 May 2006 11:17:39 -0400 (EDT) Message-ID: <44635584.5070304@columbia.edu> Date: Thu, 11 May 2006 11:17:24 -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: <200605111415.QAA18032@uw1048.wdf.sap.corp> In-Reply-To: <200605111415.QAA18032@uw1048.wdf.sap.corp> X-Enigmail-Version: 0.94.0.0 X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: Subject: Re: Updated I18N proposal 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="===============0574355099==" Errors-To: kitten-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============0574355099== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040801070401080302020204" This is a cryptographically signed message in MIME format. --------------ms040801070401080302020204 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Martin Rex wrote: > There is no reference to Latin-1 at the abstract API today, > and I believe there never was. > > > -Martin The only reference to Latin-1 is in the C Bindings Section 3.2.2 Character Strings. Jeffrey Altman --------------ms040801070401080302020204 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 DxcNMDYwNTExMTUxNzI0WjAjBgkqhkiG9w0BCQQxFgQUOmJuWmqpl9AU8LEm+laC+zHd8Iow UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw7NrDB6BgsqhkiG9w0B CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AgMOzawwDQYJKoZIhvcNAQEBBQAEggEAhebx2umgEYFI+I0gr7FgWnHhbBhjqa4m8F9dXFyP 90UW2iRnfd7uI0Ia5gFEmwRNxDlZ/QYMaFnAmBGlhb6fLf4uqrdrUk8lZzW16yk130adAhZv 8TZ2B8tQm2z5qkQ27Cn8ptTTYt6Xh3JZJolekUiICDRkjK3i4MRViaEmTwKSg1QfhGY8VaGp d8B2ypXg8c28iOMTnYcJLFzGpTQmAvC5LYp5DwUBVApIHxaevJxuRHISow+qiOWqyg3l2T1t VNC/irDQacaM0G1oJpDd74Eikm2ol0Th+oFftVo3n2HUJPlpwfAL9ZaOK7Uxgh3iFzmjHOj+ VlesH3Vfdu0tawAAAAAAAA== --------------ms040801070401080302020204-- --===============0574355099== 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 --===============0574355099==-- From kitten-bounces@lists.ietf.org Thu May 11 11:21:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeCyT-0007N5-IJ; Thu, 11 May 2006 11:21:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeCyT-0007N0-0j for kitten@ietf.org; Thu, 11 May 2006 11:21:09 -0400 Received: from chokecherry.srv.cs.cmu.edu ([128.2.185.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeCyR-0006NK-Qh for kitten@ietf.org; Thu, 11 May 2006 11:21: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 k4BFL6tR005866 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 11 May 2006 11:21:06 -0400 (EDT) Date: Thu, 11 May 2006 11:21:06 -0400 From: Jeffrey Hutzelman To: martin.rex@sap.com Message-ID: <2604E238540B4C99A7C73364@sirius.fac.cs.cmu.edu> In-Reply-To: <200605111415.QAA18032@uw1048.wdf.sap.corp> References: <200605111415.QAA18032@uw1048.wdf.sap.corp> Originator-Info: login-token=Mulberry:01ZsGMmtApAQ6yDAQbmT+8Cf0zw8Xt9QXTNrr/nEE=; 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: 79899194edc4f33a41f49410777972f8 Cc: kitten@ietf.org, Nicolas.Williams@sun.com, Jeffrey Hutzelman Subject: Re: Updated I18N proposal 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, May 11, 2006 04:15:21 PM +0200 Martin Rex wrote: >> One thing we do need to do is _remove_ the Latin-1 requirement from the >> abstract API, where it doesn't belong, and push it down to the >> C-language bindings. > > There is no reference to Latin-1 at the abstract API today, > and I believe there never was. You're right; the only reference to Latin-1 is in the C-language bindings. Even that text is not very precise; it only says that "certain" data items "may be regarded" as Latin-1 strings; aside from a few examples, it doesn't say which ones. The abstract API should be precise about what things are strings, and the language bindings should make it clear what the charset is for every string parameter. -- Jeff _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu May 11 14:55:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeGJx-0007k0-BW; Thu, 11 May 2006 14:55:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeGJw-0007jv-0d for kitten@ietf.org; Thu, 11 May 2006 14:55:32 -0400 Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeGJu-0007tZ-KU for kitten@ietf.org; Thu, 11 May 2006 14:55:31 -0400 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id UAA25674; Thu, 11 May 2006 20:55:22 +0200 (MESZ) From: Martin Rex Message-Id: <200605111855.UAA23157@uw1048.wdf.sap.corp> To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Thu, 11 May 2006 20:55:22 +0200 (MET DST) In-Reply-To: <20060511145346.GR28647@binky.Central.Sun.COM> from "Nicolas Williams" at May 11, 6 09:53:47 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-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: kitten@ietf.org, jhutz@cmu.edu Subject: Re: Updated I18N proposal 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: > > I agree! The abstract API spec should say something about I18N though, > something that amounts to saying that language bindings authors need to > take care of it, possibly recommending the use of Unicode. Although I do agree it would be good to have that, and I definitely want to see in when rfc2743 requires real changes (e.g. GSS-API v3), I think it would be overkill if we opt for updating only the C-Bindings in a GSS-API v2u2 style. > > > There is still the question of when the *_locale versions must be > > implemented, and what charsets are required under what conditions. My > > previous proposal in this area is still relevant, and I have seen neither > > comments on that nor alternate proposals. > > I think they must be present but may return an error if not implemented. I strongly disagree. Several functions in GSS-API v2 are new (not present in GSS-API v1) and optional (such as gss_export_sec_context/gss_import_sec_context), and furthermore the message protection calls were renamed gss_seal/gss_unseal -> gss_wrap/gss_unwrap, so having to provide a function pointer for a function that you don't want to implement is somewhat alien to the gssapi history. Applications have to deal with absence of optional functions and renamed functions anyway -- and I will definitely will not provide any of the locale functions in gssapi libraries that I create/distribute. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu May 11 14:59:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeGNT-00012o-0m; Thu, 11 May 2006 14:59:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeGNR-0000xL-Dv for kitten@ietf.org; Thu, 11 May 2006 14:59:09 -0400 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeGNQ-00085T-1k for kitten@ietf.org; Thu, 11 May 2006 14:59:09 -0400 Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id k4BIx7SX011759 for ; Thu, 11 May 2006 12:59:07 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k4BIwe6a012424 for ; Thu, 11 May 2006 12:58: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 k4BIx6eN000998; Thu, 11 May 2006 13:59:06 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k4BIx51v000997; Thu, 11 May 2006 13:59:05 -0500 (CDT) Date: Thu, 11 May 2006 13:59:05 -0500 From: Nicolas Williams To: Martin Rex Message-ID: <20060511185904.GC950@binky.Central.Sun.COM> Mail-Followup-To: Martin Rex , jhutz@cmu.edu, jaltman@columbia.edu, kitten@ietf.org References: <20060511145346.GR28647@binky.Central.Sun.COM> <200605111855.UAA23157@uw1048.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200605111855.UAA23157@uw1048.wdf.sap.corp> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: kitten@ietf.org, jhutz@cmu.edu Subject: Re: Updated I18N proposal 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, May 11, 2006 at 08:55:22PM +0200, Martin Rex wrote: > Nicolas Williams wrote: > > I think they must be present but may return an error if not implemented. > > I strongly disagree. > > Several functions in GSS-API v2 are new (not present in GSS-API v1) > and optional (such as gss_export_sec_context/gss_import_sec_context), > and furthermore the message protection calls were renamed > > gss_seal/gss_unseal -> gss_wrap/gss_unwrap, > > so having to provide a function pointer for a function that you > don't want to implement is somewhat alien to the gssapi history. > > Applications have to deal with absence of optional functions and > renamed functions anyway -- and I will definitely will not provide > any of the locale functions in gssapi libraries that I create/distribute. For v2u2, I agree, for v3 we can require that all of these be present... Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu May 11 15:10:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeGYi-0003h7-5h; Thu, 11 May 2006 15:10:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeGYh-0003h2-4L for kitten@ietf.org; Thu, 11 May 2006 15:10:47 -0400 Received: from chokecherry.srv.cs.cmu.edu ([128.2.185.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeGYf-0008Ud-Sd for kitten@ietf.org; Thu, 11 May 2006 15:10: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 k4BJAYdY013179 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 11 May 2006 15:10:35 -0400 (EDT) Date: Thu, 11 May 2006 15:10:34 -0400 From: Jeffrey Hutzelman To: Nicolas Williams , Martin Rex Message-ID: In-Reply-To: <20060511185904.GC950@binky.Central.Sun.COM> References: <20060511145346.GR28647@binky.Central.Sun.COM> <200605111855.UAA23157@uw1048.wdf.sap.corp> <20060511185904.GC950@binky.Central.Sun.COM> Originator-Info: login-token=Mulberry:01N2Ur6qHNoF6DsKNrauNbWc7XYhW+maSk2llPbeU=; 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: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: kitten@ietf.org, Jeffrey Hutzelman Subject: Re: Updated I18N proposal 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, May 11, 2006 01:59:05 PM -0500 Nicolas Williams wrote: > On Thu, May 11, 2006 at 08:55:22PM +0200, Martin Rex wrote: >> Nicolas Williams wrote: >> > I think they must be present but may return an error if not >> > implemented. >> >> I strongly disagree. >> >> Several functions in GSS-API v2 are new (not present in GSS-API v1) >> and optional (such as gss_export_sec_context/gss_import_sec_context), >> and furthermore the message protection calls were renamed >> >> gss_seal/gss_unseal -> gss_wrap/gss_unwrap, >> >> so having to provide a function pointer for a function that you >> don't want to implement is somewhat alien to the gssapi history. >> >> Applications have to deal with absence of optional functions and >> renamed functions anyway -- and I will definitely will not provide >> any of the locale functions in gssapi libraries that I create/distribute. > > For v2u2, I agree, for v3 we can require that all of these be present... For v2u2, none of these will be present, as we are not empowered to change the existing API, only to clarify it. For v3, I happen to agree with Martin's position that the *_locale functions should simply not exist if not implemented. However, I very strongly object to his method of argument, which basically boils down to "you better do it my way because if you don't I'm going to ignore the spec and do it my way anyway". -- Jeff _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu May 11 15:13:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeGbf-0004cN-OG; Thu, 11 May 2006 15:13:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeGbe-0004cI-1W for kitten@ietf.org; Thu, 11 May 2006 15:13:50 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeGbc-0000Kw-P1 for kitten@ietf.org; Thu, 11 May 2006 15:13:50 -0400 Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id k4BJDmxW017242 for ; Thu, 11 May 2006 13:13:48 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k4BJDK37018879 for ; Thu, 11 May 2006 13:13: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 k4BJDl5E001022; Thu, 11 May 2006 14:13:47 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k4BJDlT4001021; Thu, 11 May 2006 14:13:47 -0500 (CDT) Date: Thu, 11 May 2006 14:13:47 -0500 From: Nicolas Williams To: Jeffrey Hutzelman Message-ID: <20060511191347.GD950@binky.Central.Sun.COM> Mail-Followup-To: Jeffrey Hutzelman , Martin Rex , jaltman@columbia.edu, kitten@ietf.org References: <20060511145346.GR28647@binky.Central.Sun.COM> <200605111855.UAA23157@uw1048.wdf.sap.corp> <20060511185904.GC950@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: cf4fa59384e76e63313391b70cd0dd25 Cc: kitten@ietf.org Subject: Re: Updated I18N proposal 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, May 11, 2006 at 03:10:34PM -0400, Jeffrey Hutzelman wrote: > For v2u2, none of these will be present, as we are not empowered to change > the existing API, only to clarify it. That depends on what the new charter says w.r.t. I18N. I've not seen the text. > For v3, I happen to agree with Martin's position that the *_locale > functions should simply not exist if not implemented. However, I very > strongly object to his method of argument, which basically boils down to > "you better do it my way because if you don't I'm going to ignore the spec > and do it my way anyway". I see no reason why in the v3 baseline we couldn't require all functions to exist, but I also don't take a very strong position on this particular matter. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu May 11 15:59:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeHJV-0005HR-Pe; Thu, 11 May 2006 15:59:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeHJU-0005CZ-6j for kitten@ietf.org; Thu, 11 May 2006 15:59:08 -0400 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeHJT-0002cz-Pa for kitten@ietf.org; Thu, 11 May 2006 15:59:08 -0400 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id VAA25754; Thu, 11 May 2006 21:58:51 +0200 (MESZ) From: Martin Rex Message-Id: <200605111958.VAA24539@uw1048.wdf.sap.corp> To: jhutz@cmu.edu (Jeffrey Hutzelman) Date: Thu, 11 May 2006 21:58:51 +0200 (MET DST) In-Reply-To: from "Jeffrey Hutzelman" at May 11, 6 03:10:34 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: e1e48a527f609d1be2bc8d8a70eb76cb Cc: kitten@ietf.org, Nicolas.Williams@sun.com, jhutz@cmu.edu Subject: Re: Updated I18N proposal 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: > > For v2u2, none of these will be present, as we are not empowered to change > the existing API, only to clarify it. > > For v3, I happen to agree with Martin's position that the *_locale > functions should simply not exist if not implemented. However, I very > strongly object to his method of argument, which basically boils down to > "you better do it my way because if you don't I'm going to ignore the spec > and do it my way anyway". Sorry, I didn't mean to offend you personally, just wanted to clarify that I take the liberty to entirely ignore a detail in a spec that I consider a poor/inapropriate design choice. There are a few things in rfc3280 and in the X.509v3 Standard that I handle this way, including the "subjectKeyIdentifier" presence, isCA presence in EndEntity certs and criticality of certain attributes. In GSS-API v2 there is unnecessary bloat with the OID_set utility functions (which I did implement just for the same of the fun of it, but which I would never expect to be provide from a gssapi v2 mechanism, and the fubar-ed gss-api call gss_add_cred(). I do not mind if some gssapi mechanism implemented the three gssapi call we were discussing to use the locale (and correct codepage-conversions) instead of iso-8859-1 as the C-bindings says, because it is at least slightly ambiguous. John Wray (the author of the C-Bindings document) posted a significantly more explicit statement on the use of ISO-8859-1 on the CAT Mailing list -- but that is not part of the official standard, and one cannot blame implementors for this. Really, it is much easier if you can check whether some library implements a functionality with a simple "nm libxyz.so" or "dumpbin /exports xyz32.dll" than having to write code, compile, run and look at the return code in order to find out. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu May 11 16:08:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeHSQ-0000Sa-Ub; Thu, 11 May 2006 16:08:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeHSL-0000SG-Ni for kitten@ietf.org; Thu, 11 May 2006 16:08:17 -0400 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeHSL-0003IB-AK for kitten@ietf.org; Thu, 11 May 2006 16:08:17 -0400 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id k4BK8Gif023200 for ; Thu, 11 May 2006 13:08:16 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k4BK8Fa8028318 for ; Thu, 11 May 2006 14:08:16 -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 k4BK8F5U001068; Thu, 11 May 2006 15:08:15 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k4BK8F68001067; Thu, 11 May 2006 15:08:15 -0500 (CDT) Date: Thu, 11 May 2006 15:08:15 -0500 From: Nicolas Williams To: Martin Rex Message-ID: <20060511200814.GF950@binky.Central.Sun.COM> Mail-Followup-To: Martin Rex , Jeffrey Hutzelman , jaltman@columbia.edu, kitten@ietf.org References: <200605111958.VAA24539@uw1048.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200605111958.VAA24539@uw1048.wdf.sap.corp> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: kitten@ietf.org, Jeffrey Hutzelman Subject: Re: Updated I18N proposal 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, May 11, 2006 at 09:58:51PM +0200, Martin Rex wrote: > Jeffrey Hutzelman wrote: > > For v3, I happen to agree with Martin's position that the *_locale > > functions should simply not exist if not implemented. However, I very > > strongly object to his method of argument, which basically boils down to > > "you better do it my way because if you don't I'm going to ignore the spec > > and do it my way anyway". > > Sorry, I didn't mean to offend you personally, just wanted to clarify > that I take the liberty to entirely ignore a detail in a spec that > I consider a poor/inapropriate design choice. There are a few things > in rfc3280 and in the X.509v3 Standard that I handle this way, > including the "subjectKeyIdentifier" presence, isCA presence in > EndEntity certs and criticality of certain attributes. Er, OK then. Obviously specs can have mistakes, or parts of them may be much too difficult to implement. So we have to take some liberties. We should prefer to take as few such liberties as possible. > In GSS-API v2 there is unnecessary bloat with the OID_set utility > functions (which I did implement just for the same of the fun of it, > but which I would never expect to be provide from a gssapi v2 mechanism, > and the fubar-ed gss-api call gss_add_cred(). Remind me, off-list, what's wrong with gss_add_cred(). > I do not mind if some gssapi mechanism implemented the three gssapi > call we were discussing to use the locale (and correct codepage-conversions) > instead of iso-8859-1 as the C-bindings says, because it is at least > slightly ambiguous. John Wray (the author of the C-Bindings document) > posted a significantly more explicit statement on the use of ISO-8859-1 > on the CAT Mailing list -- but that is not part of the official standard, > and one cannot blame implementors for this. I didn't either, but now that it's clear that you have implementations which conflict with ours on this I do mind and I do want a better solution than "ignore what the spec says." > Really, it is much easier if you can check whether some library implements > a functionality with a simple "nm libxyz.so" or "dumpbin /exports xyz32.dll" > than having to write code, compile, run and look at the return code in > order to find out. Ideally there should be pre-processor defines... But one can do all this work at run-time (provided one has a modern run-time linker). Still, it'd be even better if all functions in the baseline API are guaranteed to be present, even if all some optional ones do is return errors. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu May 11 16:31:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeHp9-0005qa-GF; Thu, 11 May 2006 16:31:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeHp8-0005qV-BD for kitten@ietf.org; Thu, 11 May 2006 16:31:50 -0400 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeHp6-0004Vg-UH for kitten@ietf.org; Thu, 11 May 2006 16:31:50 -0400 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id k4BKVmSX005846 for ; Thu, 11 May 2006 14:31:48 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k4BKVlCh009674 for ; Thu, 11 May 2006 14:31:48 -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 k4BKVlCn001108; Thu, 11 May 2006 15:31:47 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k4BKVlRW001107; Thu, 11 May 2006 15:31:47 -0500 (CDT) Date: Thu, 11 May 2006 15:31:47 -0500 From: Nicolas Williams To: Jeffrey Hutzelman Message-ID: <20060511203147.GA1091@binky.Central.Sun.COM> Mail-Followup-To: Jeffrey Hutzelman , Martin Rex , jaltman@columbia.edu, kitten@ietf.org References: <200605111958.VAA24539@uw1048.wdf.sap.corp> <20060511200814.GF950@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: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: kitten@ietf.org Subject: Re: Updated I18N proposal 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, May 11, 2006 at 04:12:42PM -0400, Jeffrey Hutzelman wrote: > Things that require running code to perform a configure test are evil. > If you have to run code to do a test, you can't do that test in a > cross-compile environment. I didn't say that compile-time tests are bad... And, BTW, I don't agree with what you say, witness Java. Given a sufficiently rich run-time then relying on run-time detection of features is a good thing. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu May 11 16:33:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeHqH-0007ui-Sn; Thu, 11 May 2006 16:33:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeHqH-0007ud-FE for kitten@ietf.org; Thu, 11 May 2006 16:33:01 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeHqG-0004ZJ-8f for kitten@ietf.org; Thu, 11 May 2006 16:33:01 -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 k4BKWx8D016052 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 11 May 2006 16:32:59 -0400 (EDT) Message-ID: <44639F69.2030004@columbia.edu> Date: Thu, 11 May 2006 16:32:41 -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: <200605111958.VAA24539@uw1048.wdf.sap.corp> <20060511200814.GF950@binky.Central.Sun.COM> <20060511203147.GA1091@binky.Central.Sun.COM> In-Reply-To: <20060511203147.GA1091@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: Updated I18N proposal 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="===============1063516063==" Errors-To: kitten-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============1063516063== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040104070902090409030802" This is a cryptographically signed message in MIME format. --------------ms040104070902090409030802 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Nicolas Williams wrote: > On Thu, May 11, 2006 at 04:12:42PM -0400, Jeffrey Hutzelman wrote: >> Things that require running code to perform a configure test are evil. >> If you have to run code to do a test, you can't do that test in a >> cross-compile environment. > > I didn't say that compile-time tests are bad... > > And, BTW, I don't agree with what you say, witness Java. > > Given a sufficiently rich run-time then relying on run-time detection of > features is a good thing. > > Nico I want my cake and eat it to. I would like run-time detection and compile time detection. Jeffrey Altman --------------ms040104070902090409030802 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 DxcNMDYwNTExMjAzMjQxWjAjBgkqhkiG9w0BCQQxFgQU1dN5qwZkWEARMmnjWKtoyokwChMw UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw7NrDB6BgsqhkiG9w0B CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AgMOzawwDQYJKoZIhvcNAQEBBQAEggEAHsrjZ0gQlJfy9TOXouJajBzct46yQLG2romZTNlT OtpB1sxkOAZYl2erswZ3j93GxwmrsJvKVelYoa4Hc/clvYnXRS/6OPjvxvaVEuc8HTXwfqmV 1MenrTa3oT2Zr/rceGzAMG6ghUqE4gNhsykmw965G61F/52A6ZGmhn6K0113MihYiLgwjnsD p/Om0GlUYOWgXJyBdv9cnHIUioxfAVZu8RJSJq9Ncgxqf81dgF281Ey6LYc6Pb3z9iF/lB8l d7oMKq6MaOFK/ia4XqWwdqqZ6aIDPx8ADUu5mij2rDE1EnkgjMhVHsS9x6/K6Hoxc425VISK l1BiN3lMJyWKOAAAAAAAAA== --------------ms040104070902090409030802-- --===============1063516063== 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 --===============1063516063==-- From kitten-bounces@lists.ietf.org Thu May 11 16:44:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeI1W-0000NY-5S; Thu, 11 May 2006 16:44:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeI1V-0000NT-Sb for kitten@ietf.org; Thu, 11 May 2006 16:44:37 -0400 Received: from nwkea-mail-4.sun.com ([192.18.42.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeI1U-0005Hq-GG for kitten@ietf.org; Thu, 11 May 2006 16:44:37 -0400 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by nwkea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id k4BKiZUm003077 for ; Thu, 11 May 2006 13:44:35 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k4BKiYh9014811 for ; Thu, 11 May 2006 14:44:35 -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 k4BKiY3O001117; Thu, 11 May 2006 15:44:34 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k4BKiYDi001116; Thu, 11 May 2006 15:44:34 -0500 (CDT) Date: Thu, 11 May 2006 15:44:34 -0500 From: Nicolas Williams To: Jeffrey Altman Message-ID: <20060511204434.GB1091@binky.Central.Sun.COM> Mail-Followup-To: Jeffrey Altman , kitten@ietf.org References: <200605111958.VAA24539@uw1048.wdf.sap.corp> <20060511200814.GF950@binky.Central.Sun.COM> <20060511203147.GA1091@binky.Central.Sun.COM> <44639F69.2030004@columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44639F69.2030004@columbia.edu> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: kitten@ietf.org Subject: Re: Updated I18N proposal 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, May 11, 2006 at 04:32:41PM -0400, Jeffrey Altman wrote: > Nicolas Williams wrote: > > On Thu, May 11, 2006 at 04:12:42PM -0400, Jeffrey Hutzelman wrote: > >> Things that require running code to perform a configure test are evil. > >> If you have to run code to do a test, you can't do that test in a > >> cross-compile environment. > > > > I didn't say that compile-time tests are bad... > > > > And, BTW, I don't agree with what you say, witness Java. > > > > Given a sufficiently rich run-time then relying on run-time detection of > > features is a good thing. > > > > Nico > > I want my cake and eat it to. I would like run-time detection > and compile time detection. Exactly. The only problem is that for the C bindings we can only portably specify compile-time feature detection, and we can't even specify exactly how to find the header file. Yes, C can suck. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu May 11 16:56:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeICs-0003hU-8s; Thu, 11 May 2006 16:56:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeICr-0003hK-1G for kitten@ietf.org; Thu, 11 May 2006 16:56:21 -0400 Received: from chokecherry.srv.cs.cmu.edu ([128.2.185.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeICp-00069D-PI for kitten@ietf.org; Thu, 11 May 2006 16:56:21 -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 k4BKuEjK016357 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 11 May 2006 16:56:15 -0400 (EDT) Date: Thu, 11 May 2006 16:56:14 -0400 From: Jeffrey Hutzelman To: Jeffrey Altman , kitten@ietf.org Message-ID: <44B2E5D054169C72DDCDC159@sirius.fac.cs.cmu.edu> In-Reply-To: <44639F69.2030004@columbia.edu> References: <200605111958.VAA24539@uw1048.wdf.sap.corp> <20060511200814.GF950@binky.Central.Sun.COM> <20060511203147.GA1091@binky.Central.Sun.COM> <44639F69.2030004@columbia.edu> Originator-Info: login-token=Mulberry:011lkc8kDBkWYipJRzCddMYW3LUx1djZVDzkpXDNk=; 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: 52e1467c2184c31006318542db5614d5 Cc: Jeffrey Hutzelman Subject: Re: Updated I18N proposal 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, May 11, 2006 04:32:41 PM -0400 Jeffrey Altman wrote: > Nicolas Williams wrote: >> On Thu, May 11, 2006 at 04:12:42PM -0400, Jeffrey Hutzelman wrote: >>> Things that require running code to perform a configure test are evil. >>> If you have to run code to do a test, you can't do that test in a >>> cross-compile environment. >> >> I didn't say that compile-time tests are bad... >> >> And, BTW, I don't agree with what you say, witness Java. >> >> Given a sufficiently rich run-time then relying on run-time detection of >> features is a good thing. >> >> Nico > > I want my cake and eat it to. I would like run-time detection > and compile time detection. Right, and my point is that "compile time detection" cannot consist of compiling and running a test program that uses the run-time detection to tell you if the feature is available, because that doesn't work in cross-compile environments. It turns out that the art of build-time feature detection is fairly well understood, at least in the UNIX/C world, and not breaking it is nice. It turns out that tests that check for existence of a type, function, preprocessor symbol, etc are fairly easy to do. Tests that check the value of a preprocessor symbol are a bit harder, and tests that require that you _call_ a function and check its behavior or return value are very poor. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu May 11 17:05:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeIM1-00047O-Ml; Thu, 11 May 2006 17:05:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeIM0-00046z-2j for kitten@ietf.org; Thu, 11 May 2006 17:05:48 -0400 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeILy-0006Xq-LE for kitten@ietf.org; Thu, 11 May 2006 17:05:48 -0400 Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id k4BL5kSX027004 for ; Thu, 11 May 2006 15:05:46 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k4BL5Ief004567 for ; Thu, 11 May 2006 15:05:19 -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 k4BL5j7B001260; Thu, 11 May 2006 16:05:45 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k4BL5iXh001259; Thu, 11 May 2006 16:05:44 -0500 (CDT) Date: Thu, 11 May 2006 16:05:44 -0500 From: Nicolas Williams To: Jeffrey Hutzelman Message-ID: <20060511210544.GA1120@binky.Central.Sun.COM> Mail-Followup-To: Jeffrey Hutzelman , Jeffrey Altman , kitten@ietf.org References: <200605111958.VAA24539@uw1048.wdf.sap.corp> <20060511200814.GF950@binky.Central.Sun.COM> <20060511203147.GA1091@binky.Central.Sun.COM> <44639F69.2030004@columbia.edu> <44B2E5D054169C72DDCDC159@sirius.fac.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44B2E5D054169C72DDCDC159@sirius.fac.cs.cmu.edu> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: kitten@ietf.org Subject: Re: Updated I18N proposal 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, May 11, 2006 at 04:56:14PM -0400, Jeffrey Hutzelman wrote: > Right, and my point is that "compile time detection" cannot consist of > compiling and running a test program that uses the run-time detection to > tell you if the feature is available, because that doesn't work in > cross-compile environments. > > It turns out that the art of build-time feature detection is fairly well > understood, at least in the UNIX/C world, and not breaking it is nice. It > turns out that tests that check for existence of a type, function, > preprocessor symbol, etc are fairly easy to do. Tests that check the value > of a preprocessor symbol are a bit harder, and tests that require that you > _call_ a function and check its behavior or return value are very poor. I see this point, but C code that would use functions that may optionally do nothing and return errors SHOULD always do run-time detection of this and SHOULD NOT rely on compile-time detection of such features. Again, I'm not remotely opposed to have pre-processor defines for compile-time detection of features. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu May 11 17:17:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeIXW-00065t-J6; Thu, 11 May 2006 17:17:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeIXV-00065o-LX for kitten@ietf.org; Thu, 11 May 2006 17:17:41 -0400 Received: from chokecherry.srv.cs.cmu.edu ([128.2.185.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeIXU-0006tX-DV for kitten@ietf.org; Thu, 11 May 2006 17:17:41 -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 k4BLHZvh016797 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 11 May 2006 17:17:36 -0400 (EDT) Date: Thu, 11 May 2006 17:17:35 -0400 From: Jeffrey Hutzelman To: Nicolas Williams Message-ID: <5CE77D4530B29A93C349D0AA@sirius.fac.cs.cmu.edu> In-Reply-To: <20060511210544.GA1120@binky.Central.Sun.COM> References: <200605111958.VAA24539@uw1048.wdf.sap.corp> <20060511200814.GF950@binky.Central.Sun.COM> <20060511203147.GA1091@binky.Central.Sun.COM> <44639F69.2030004@columbia.edu> <44B2E5D054169C72DDCDC159@sirius.fac.cs.cmu.edu> <20060511210544.GA1120@binky.Central.Sun.COM> Originator-Info: login-token=Mulberry:011vobaUBikN0iRZPqCXhL2G1sUpRdLpRDb0nODHo=; 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: 2409bba43e9c8d580670fda8b695204a Cc: kitten@ietf.org, Jeffrey Hutzelman Subject: Re: Updated I18N proposal 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, May 11, 2006 04:05:44 PM -0500 Nicolas Williams wrote: > On Thu, May 11, 2006 at 04:56:14PM -0400, Jeffrey Hutzelman wrote: >> Right, and my point is that "compile time detection" cannot consist of >> compiling and running a test program that uses the run-time detection to >> tell you if the feature is available, because that doesn't work in >> cross-compile environments. >> >> It turns out that the art of build-time feature detection is fairly well >> understood, at least in the UNIX/C world, and not breaking it is nice. >> It turns out that tests that check for existence of a type, function, >> preprocessor symbol, etc are fairly easy to do. Tests that check the >> value of a preprocessor symbol are a bit harder, and tests that require >> that you _call_ a function and check its behavior or return value are >> very poor. > > I see this point, but C code that would use functions that may > optionally do nothing and return errors SHOULD always do run-time > detection of this and SHOULD NOT rely on compile-time detection of such > features. Ah, but if those functions aren't implemented, then maybe I want to compile in additional code that emulates them. To do that, I _need_ to know the answer at compile time. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu May 11 17:24:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeIeL-00035j-Lt; Thu, 11 May 2006 17:24:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeIeK-00035e-JI for kitten@ietf.org; Thu, 11 May 2006 17:24:44 -0400 Received: from chokecherry.srv.cs.cmu.edu ([128.2.185.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeIeK-00072h-DP for kitten@ietf.org; Thu, 11 May 2006 17:24:44 -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 k4BLOh1x016919 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 11 May 2006 17:24:43 -0400 (EDT) Date: Thu, 11 May 2006 17:24:43 -0400 From: Jeffrey Hutzelman To: Nicolas Williams Message-ID: <6E7DE3ABD300BC901265C9FF@sirius.fac.cs.cmu.edu> In-Reply-To: <20060511210544.GA1120@binky.Central.Sun.COM> References: <200605111958.VAA24539@uw1048.wdf.sap.corp> <20060511200814.GF950@binky.Central.Sun.COM> <20060511203147.GA1091@binky.Central.Sun.COM> <44639F69.2030004@columbia.edu> <44B2E5D054169C72DDCDC159@sirius.fac.cs.cmu.edu> <20060511210544.GA1120@binky.Central.Sun.COM> Originator-Info: login-token=Mulberry:01twC4XiFoLdIDSzDf6n7ozU5y74k+NDEkdebD7YA=; 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: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: kitten@ietf.org, Jeffrey Hutzelman Subject: Re: Updated I18N proposal 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, May 11, 2006 04:05:44 PM -0500 Nicolas Williams wrote: > Again, I'm not remotely opposed to have pre-processor defines for > compile-time detection of features. Then I don't think we have a problem. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu May 11 17:26:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeIfZ-0003Gd-EM; Thu, 11 May 2006 17:26:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeIfX-0003G1-LY for kitten@ietf.org; Thu, 11 May 2006 17:25:59 -0400 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeIfV-00077x-59 for kitten@ietf.org; Thu, 11 May 2006 17:25:59 -0400 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id k4BLPurM014811 for ; Thu, 11 May 2006 14:25:56 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k4BLPtYd007081 for ; Thu, 11 May 2006 15:25:55 -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 k4BLPt5v001328; Thu, 11 May 2006 16:25:55 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k4BLPtJt001327; Thu, 11 May 2006 16:25:55 -0500 (CDT) Date: Thu, 11 May 2006 16:25:55 -0500 From: Nicolas Williams To: Jeffrey Hutzelman Message-ID: <20060511212554.GB1120@binky.Central.Sun.COM> Mail-Followup-To: Jeffrey Hutzelman , Jeffrey Altman , kitten@ietf.org References: <200605111958.VAA24539@uw1048.wdf.sap.corp> <20060511200814.GF950@binky.Central.Sun.COM> <20060511203147.GA1091@binky.Central.Sun.COM> <44639F69.2030004@columbia.edu> <44B2E5D054169C72DDCDC159@sirius.fac.cs.cmu.edu> <20060511210544.GA1120@binky.Central.Sun.COM> <5CE77D4530B29A93C349D0AA@sirius.fac.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5CE77D4530B29A93C349D0AA@sirius.fac.cs.cmu.edu> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: kitten@ietf.org Subject: Re: Updated I18N proposal 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, May 11, 2006 at 05:17:35PM -0400, Jeffrey Hutzelman wrote: > > > On Thursday, May 11, 2006 04:05:44 PM -0500 Nicolas Williams > wrote: > > >On Thu, May 11, 2006 at 04:56:14PM -0400, Jeffrey Hutzelman wrote: > >>Right, and my point is that "compile time detection" cannot consist of > >>compiling and running a test program that uses the run-time detection to > >>tell you if the feature is available, because that doesn't work in > >>cross-compile environments. > >> > >>It turns out that the art of build-time feature detection is fairly well > >>understood, at least in the UNIX/C world, and not breaking it is nice. > >>It turns out that tests that check for existence of a type, function, > >>preprocessor symbol, etc are fairly easy to do. Tests that check the > >>value of a preprocessor symbol are a bit harder, and tests that require > >>that you _call_ a function and check its behavior or return value are > >>very poor. > > > >I see this point, but C code that would use functions that may > >optionally do nothing and return errors SHOULD always do run-time > >detection of this and SHOULD NOT rely on compile-time detection of such > >features. > > Ah, but if those functions aren't implemented, then maybe I want to compile > in additional code that emulates them. To do that, I _need_ to know the > answer at compile time. And I will repeat this one last time: I don't oppose having C prep-processor defines for this. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu May 11 18:29:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeJfB-0000Sv-Qc; Thu, 11 May 2006 18:29:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeJfA-0000Sq-BM for kitten@ietf.org; Thu, 11 May 2006 18:29:40 -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 1FeHfH-0003op-Fi for kitten@ietf.org; Thu, 11 May 2006 16:21:39 -0400 Received: from chokecherry.srv.cs.cmu.edu ([128.2.185.41]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FeHWk-0004k2-48 for kitten@ietf.org; Thu, 11 May 2006 16:12:52 -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 k4BKCgtR015137 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 11 May 2006 16:12:43 -0400 (EDT) Date: Thu, 11 May 2006 16:12:42 -0400 From: Jeffrey Hutzelman To: Nicolas Williams , Martin Rex Message-ID: In-Reply-To: <20060511200814.GF950@binky.Central.Sun.COM> References: <200605111958.VAA24539@uw1048.wdf.sap.corp> <20060511200814.GF950@binky.Central.Sun.COM> Originator-Info: login-token=Mulberry:01oa28XQsVMdHt+DTe1CvszDgf84go4TUOIurC1y0=; 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: -2.6 (--) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: kitten@ietf.org, Jeffrey Hutzelman Subject: Re: Updated I18N proposal 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, May 11, 2006 03:08:15 PM -0500 Nicolas Williams wrote: >> Really, it is much easier if you can check whether some library >> implements a functionality with a simple "nm libxyz.so" or "dumpbin >> /exports xyz32.dll" than having to write code, compile, run and look at >> the return code in order to find out. > > Ideally there should be pre-processor defines... But one can do all > this work at run-time (provided one has a modern run-time linker). > Still, it'd be even better if all functions in the baseline API are > guaranteed to be present, even if all some optional ones do is return > errors. Things that require running code to perform a configure test are evil. If you have to run code to do a test, you can't do that test in a cross-compile environment. -- Jeff _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Fri May 12 12:37:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Feadw-0008J4-Jy; Fri, 12 May 2006 12:37:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Feadw-0008Iz-07 for kitten@ietf.org; Fri, 12 May 2006 12:37:32 -0400 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Feadu-00058g-Io for kitten@ietf.org; Fri, 12 May 2006 12:37:31 -0400 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id SAA15900; Fri, 12 May 2006 18:37:16 +0200 (MESZ) From: Martin Rex Message-Id: <200605121637.SAA07590@uw1048.wdf.sap.corp> To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Fri, 12 May 2006 18:37:05 +0200 (MET DST) In-Reply-To: <20060511204434.GB1091@binky.Central.Sun.COM> from "Nicolas Williams" at May 11, 6 03:44:34 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: 769a46790fb42fbb0b0cc700c82f7081 Cc: kitten@ietf.org Subject: Re: Updated I18N proposal 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: > > The only problem is that for the C bindings we can only portably specify > compile-time feature detection, and we can't even specify exactly how to > find the header file. > > Yes, C can suck. Not if you do it correctly. We use binary plug'n'play exclusively, i.e. runtime dynamic loading of a third party shared library via dlopen/LoadLibrary on all of our platforms with any of the 15 gssapi mechanism that are certified for interoperability and a few more. You're out for much worse experiences when you have your application compiled with C++ compiler A and try to dynamically load at runtime a shared library from a third party vendor that was compiled with a different C++ compiler and different class libraries. I think the problem occurs because the shared library is incorrectly built (in combination with the global symbol space of the Unix loader) but I'm still waiting for the resolution. We have been using a gssapi_2.h header file based on the appendix or the C-Bindings document with slight modifications. We do not use the broken xom.h OID/OID_set definitions, but instead the fallback definitions compatible to what MIT Kerberos 5 has been using in 1995/1996 (the difference affects 64-bit platforms), because we needed to be binary compatible to MIT Kerberos on Digital Unix. Determining the features of a gssapi mechanism by the functions/symbols which can be loaded/resolved dynamically at runtime works fine and reliably. Dynamic runtime loading does not have any problem loading several seperate shared libraries that export the exact same symbols/functions without getting confused (about the dynamically loaded functions). As mentioned, if the shared library has internal symbols not fully resolved, your're up for unpleasant surprises for all meet-in-the-wild combinations of apps and shared libs on Unix. GSS-API v2 is sufficiently clear that a portable application do not need to include any product or mechanism specific header files at compile time in order to be able to use it. You might need that for some dirty mech-specific tricks, though. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Fri May 12 12:45:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FealF-0007B0-4s; Fri, 12 May 2006 12:45:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FealE-0007Av-2I for kitten@ietf.org; Fri, 12 May 2006 12:45:04 -0400 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FealB-0005ig-KG for kitten@ietf.org; Fri, 12 May 2006 12:45:04 -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 k4CGj1IH015761 for ; Fri, 12 May 2006 10:45:01 -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 k4CGixYB019781 for ; Fri, 12 May 2006 10:45: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 k4CGixjq001945; Fri, 12 May 2006 11:44:59 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k4CGiuEX001944; Fri, 12 May 2006 11:44:56 -0500 (CDT) Date: Fri, 12 May 2006 11:44:56 -0500 From: Nicolas Williams To: Martin Rex Message-ID: <20060512164456.GS1120@binky.Central.Sun.COM> Mail-Followup-To: Martin Rex , jaltman@columbia.edu, kitten@ietf.org References: <20060511204434.GB1091@binky.Central.Sun.COM> <200605121637.SAA07590@uw1048.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200605121637.SAA07590@uw1048.wdf.sap.corp> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: kitten@ietf.org Subject: Re: Updated I18N proposal 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, May 12, 2006 at 06:37:05PM +0200, Martin Rex wrote: > Nicolas Williams wrote: > > > > The only problem is that for the C bindings we can only portably specify > > compile-time feature detection, and we can't even specify exactly how to > > find the header file. > > > > Yes, C can suck. > > Not if you do it correctly. We use binary plug'n'play exclusively, > i.e. runtime dynamic loading of a third party shared library via > dlopen/LoadLibrary on all of our platforms with any of the > 15 gssapi mechanism that are certified for interoperability and a few more. Clearly. We have a very nice runtime linker in Solaris. That's not my complaint though. My complaint is that nice runtime linking isn't part of the C standard. So, can we mention runtime linking in the C bindings spec? I suspect there will be resistance. Certainly we can't offer much _detail_ as the details of modern linking vary by platform. E.g., on Solaris I'd recommend that mechglue use dlopen() with RTLD_GROUP and RTLD_LOCAL flags to load mechanisms. Does Linux's rtld provide similar options? Does MS'? Can we be sufficiently abstract in this regard? Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Fri May 12 12:53:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeatG-0003DY-Bl; Fri, 12 May 2006 12:53:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeatF-0003DT-0p for kitten@ietf.org; Fri, 12 May 2006 12:53:21 -0400 Received: from chokecherry.srv.cs.cmu.edu ([128.2.185.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeatD-0006I5-Ol for kitten@ietf.org; Fri, 12 May 2006 12:53:21 -0400 Received: from mariner.pc.cs.cmu.edu (MARINER.PC.CS.CMU.EDU [128.2.200.130]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.5/8.13.5) with ESMTP id k4CGrDQD005939 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 12 May 2006 12:53:14 -0400 (EDT) Date: Fri, 12 May 2006 12:53:13 -0400 From: Jeffrey Hutzelman To: Nicolas Williams , Martin Rex Message-ID: In-Reply-To: <20060512164456.GS1120@binky.Central.Sun.COM> References: <20060511204434.GB1091@binky.Central.Sun.COM> <200605121637.SAA07590@uw1048.wdf.sap.corp> <20060512164456.GS1120@binky.Central.Sun.COM> Originator-Info: login-token=Mulberry:01SY4+irP2s/6V2bYLfAxu+eAAdbXQwre2A2zvfw4=; 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: 9466e0365fc95844abaf7c3f15a05c7d Cc: kitten@ietf.org, Jeffrey Hutzelman Subject: Re: Updated I18N proposal 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, May 12, 2006 11:44:56 AM -0500 Nicolas Williams wrote: > So, can we mention runtime linking in the C bindings spec? I suspect > there will be resistance. Certainly we can't offer much _detail_ as the > details of modern linking vary by platform. > > E.g., on Solaris I'd recommend that mechglue use dlopen() with > RTLD_GROUP and RTLD_LOCAL flags to load mechanisms. Does Linux's rtld > provide similar options? Does MS'? Can we be sufficiently abstract in > this regard? Linux's (glibc's) rtld provides RTLD_LOCAL; in fact, it is the default, as it should be. But it doesn't provide RTLD_GROUP, which is fairly essential to the problem you're thinking of. In any case, no, I don't think the GSS-API C bindings spec is the right place to get up on that particular soapbox. Doing so is IMHO more likely to be confusing than helpful, especially since the rest of the document specifies an API, not an ABI. For example, that means that applications and mechanisms (or whatever glue is behind the API) _do_ need to agree on the exact declarations of things, what the structure types are, the values of various constants, and so on. So no, an application does not need to be built against a mechanism-specific header, but the app and meechanism need to agree on an ABI, which is outside the scope of the GSS-API spec. -- Jeff _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Fri May 12 16:52:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Feecn-0001hj-R7; Fri, 12 May 2006 16:52:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Feecm-0001hd-Qv for kitten@ietf.org; Fri, 12 May 2006 16:52:36 -0400 Received: from biscayne-one-station.mit.edu ([18.7.7.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Feecl-0002BZ-IX for kitten@ietf.org; Fri, 12 May 2006 16:52:36 -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 k4CKqYGs015126; Fri, 12 May 2006 16:52:34 -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 k4CKqTnQ022882 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Fri, 12 May 2006 16:52:31 -0400 (EDT) In-Reply-To: <200605121637.SAA07590@uw1048.wdf.sap.corp> References: <200605121637.SAA07590@uw1048.wdf.sap.corp> 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: Fri, 12 May 2006 16:52:28 -0400 To: martin.rex@sap.com 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: 79899194edc4f33a41f49410777972f8 Cc: kitten@ietf.org, Nicolas Williams Subject: Re: Updated I18N proposal 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 May 12, 2006, at 12:37, Martin Rex wrote: > Not if you do it correctly. We use binary plug'n'play exclusively, > i.e. runtime dynamic loading of a third party shared library via > dlopen/LoadLibrary on all of our platforms with any of the > 15 gssapi mechanism that are certified for interoperability and a > few more. I'm a bit surprised that this works, given the latitude granted in the C bindings spec. Stuff like "pointer or integral type", where some platforms handle pointers and integers differently in function calls, two Windows function calling conventions, and other stuff, some of which is discussed in RFC 2744 Appendix B. But if you've found that most or all implementations do behave consistently enough to have an ABI, perhaps we should see if that appendix should be updated with more specifics, or an informational doc published. Or is it the case that there are other implementations you can't use, and they're just not "certified for interoperability"? Ken _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Fri May 12 18:11:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fefr7-0007SE-JT; Fri, 12 May 2006 18:11:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fefr6-0007S9-Bf for kitten@ietf.org; Fri, 12 May 2006 18:11:28 -0400 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fefqz-0007L1-Jl for kitten@ietf.org; Fri, 12 May 2006 18:11:28 -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 k4CMBKIH005501 for ; Fri, 12 May 2006 16:11: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 k4CMBKZp024458 for ; Fri, 12 May 2006 16:11:20 -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 k4CMBKU7002353; Fri, 12 May 2006 17:11:20 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k4CMBJaK002352; Fri, 12 May 2006 17:11:19 -0500 (CDT) Date: Fri, 12 May 2006 17:11:19 -0500 From: Nicolas Williams To: Ken Raeburn Message-ID: <20060512221119.GN1120@binky.Central.Sun.COM> Mail-Followup-To: Ken Raeburn , martin.rex@sap.com, kitten@ietf.org References: <200605121637.SAA07590@uw1048.wdf.sap.corp> 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: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: kitten@ietf.org Subject: Re: Updated I18N proposal 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, May 12, 2006 at 04:52:28PM -0400, Ken Raeburn wrote: > On May 12, 2006, at 12:37, Martin Rex wrote: > >Not if you do it correctly. We use binary plug'n'play exclusively, > >i.e. runtime dynamic loading of a third party shared library via > >dlopen/LoadLibrary on all of our platforms with any of the > >15 gssapi mechanism that are certified for interoperability and a > >few more. > > I'm a bit surprised that this works, given the latitude granted in > the C bindings spec. Stuff like "pointer or integral type", where > some platforms handle pointers and integers differently in function > calls, two Windows function calling conventions, and other stuff, > some of which is discussed in RFC 2744 Appendix B. But if you've > found that most or all implementations do behave consistently enough > to have an ABI, perhaps we should see if that appendix should be > updated with more specifics, or an informational doc published. I think we might be able to have a largish non-normative appendix on ABI considerations, including advice on dynamic linking, run-time link/ loading, etc... Martin argues, privately, that we could do that (or at least that's what I understood, Martin), and I think it would be good to do that, even if it means having some platform-specific contents in there. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Sat May 13 17:18:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ff1V5-0002Ad-29; Sat, 13 May 2006 17:18:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ff1V3-0002AY-Jf for kitten@ietf.org; Sat, 13 May 2006 17:18:09 -0400 Received: from chokecherry.srv.cs.cmu.edu ([128.2.185.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ff1V2-0003A2-Cq for kitten@ietf.org; Sat, 13 May 2006 17:18: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 k4DLI4pG029383 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 13 May 2006 17:18:05 -0400 (EDT) Date: Sat, 13 May 2006 17:18:04 -0400 From: Jeffrey Hutzelman To: Nicolas Williams , Ken Raeburn Message-ID: In-Reply-To: <20060512221119.GN1120@binky.Central.Sun.COM> References: <200605121637.SAA07590@uw1048.wdf.sap.corp> <20060512221119.GN1120@binky.Central.Sun.COM> Originator-Info: login-token=Mulberry:0101kNST3Bgr0fpIXKBtc9uGrLRHRajYZAzjuuCdk=; 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: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: kitten@ietf.org, Jeffrey Hutzelman Subject: Re: Updated I18N proposal 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, May 12, 2006 05:11:19 PM -0500 Nicolas Williams wrote: > On Fri, May 12, 2006 at 04:52:28PM -0400, Ken Raeburn wrote: >> On May 12, 2006, at 12:37, Martin Rex wrote: >> > Not if you do it correctly. We use binary plug'n'play exclusively, >> > i.e. runtime dynamic loading of a third party shared library via >> > dlopen/LoadLibrary on all of our platforms with any of the >> > 15 gssapi mechanism that are certified for interoperability and a >> > few more. >> >> I'm a bit surprised that this works, given the latitude granted in >> the C bindings spec. Stuff like "pointer or integral type", where >> some platforms handle pointers and integers differently in function >> calls, two Windows function calling conventions, and other stuff, >> some of which is discussed in RFC 2744 Appendix B. But if you've >> found that most or all implementations do behave consistently enough >> to have an ABI, perhaps we should see if that appendix should be >> updated with more specifics, or an informational doc published. > > I think we might be able to have a largish non-normative appendix on ABI > considerations, including advice on dynamic linking, run-time link/ > loading, etc... Martin argues, privately, that we could do that (or at > least that's what I understood, Martin), and I think it would be good to > do that, even if it means having some platform-specific contents in > there. Maybe instead of a largish non-normative appendix, it would be appropriate to have a largish non-normatve separate document ? _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Sat May 13 18:29:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ff2cN-0002mY-TB; Sat, 13 May 2006 18:29:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ff2cM-0002mT-Oe for kitten@ietf.org; Sat, 13 May 2006 18:29:46 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ff2cL-0007ma-IK for kitten@ietf.org; Sat, 13 May 2006 18:29:46 -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 k4DMTfx7011447 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 13 May 2006 18:29:41 -0400 (EDT) Message-ID: <44665DCF.5060905@columbia.edu> Date: Sat, 13 May 2006 18:29:35 -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: <200605121637.SAA07590@uw1048.wdf.sap.corp> <20060512221119.GN1120@binky.Central.Sun.COM> In-Reply-To: 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: b7b9551d71acde901886cc48bfc088a6 Cc: kitten@ietf.org, Ken Raeburn , Nicolas Williams Subject: Re: Updated I18N proposal 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="===============0634062284==" Errors-To: kitten-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============0634062284== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000300090205010508040901" This is a cryptographically signed message in MIME format. --------------ms000300090205010508040901 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Jeffrey Hutzelman wrote: > Maybe instead of a largish non-normative appendix, it would be > appropriate to have a largish non-normatve separate document ? I would prefer an informational document as well. Jeffrey Altman --------------ms000300090205010508040901 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 DxcNMDYwNTEzMjIyOTM1WjAjBgkqhkiG9w0BCQQxFgQUJN+AYyVPhXuSeeSeW0Myw94exnIw UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw7NrDB6BgsqhkiG9w0B CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AgMOzawwDQYJKoZIhvcNAQEBBQAEggEAtR9q1gaWGLlECe8elsSBAR+5oH7YPkMH9djjE6Hg ppsrZwm6i97UooZ11JVWX3UpfbPAHNGyckYbdMMErI9T5+RKPr44lVmwvNYjM6/EV9kTzkeH fjZVKPaA1m/h3gTkM53c0kPsEGvq4qEOyilMDsN5W0vmvc0JuUupHR9zxBqG5xPIBwtuJTD1 THJ1BYREd1VTPoYEe061uC2gbep010aHriiL81JO2Yhyc9ELclY6bivEWwZgnMJk3cXRO6D+ sd3WPI7N1oCYZoCAEsJhrUT50jtyaZM56LTBTDRwwNFlfE0BNv/67BcyjZSk22i8NjvteqmR bkOERhyrWhpSmgAAAAAAAA== --------------ms000300090205010508040901-- --===============0634062284== 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 --===============0634062284==--