Re: Working Group Last Call (Take Two): Desired Enhancements to GSSAPI

On Fri, Apr 21, 2006 at 11:23:46PM +0200, Martin Rex wrote:
> Jeffrey Altman wrote:
> > This note announces the start of a two week working group last call
> > for the Kitten work item "Desired Enhancements to GSSAPI Naming".
> > http://www.ietf.org/internet-drafts/draft-ietf-kitten-gss-naming-04..txt
> 
> One thing that hasn't be addressed, but which is probably an
> issue (in particular with the IESG...):  I18N.

That is orthogonal to the naming extensions work.

> The C-Bindings document mentions at one place that printable strings
> use the ISO Latin 1 codepage, but what actual implementations of
> GSS-API mechanism really use (and what applications expect)
> varies.

Typically they use whatever the current locale demands, which is what
RFC2744 should have said all along.

> e.g. we do ship our application (and a particular oem library with
> a gssapi mechanism) for two native EBCDIC platforms (OS/390 and OS/400),
> and both use an EBCDIC codepage for the printables -- which differs
> from ISO Latin 1 even for 7-bit ASCII (IA5) characters.
> 
> Even for language bindings that natively support Unicode (like Java),
> the use of non-ASCII characters in the underlying GSS-API mechanism
> may create interoperability problems, i.e. with Kerberos 5 principal
> names and rfc1510 communication peers.

This is a mechanism-specific issue.

> It might be a good idea if a gssapi mechanism and an application caller
> (of the GSS-API C-Bindings) could agree on (or negotiate) the use of
> UTF8-strings for printables instead of the currently defined
> ISO-Latin-1 per rfc-2744 and the (de-facto) implementation defined
> behaviour of exisiting implementations.

IMO this way lies madness -- it makes the GSS-API not so generic.

I believe applications and the GSS-API functions that receive text
inputs or which produce text outputs should use the current locale and
nothing but.

We may want new major status codes to indicate codeset conversion
issues, but we can always get by with minor status codes.

Mechanisms should do, in their tokens and protocols, whatever their
specifications say, converting to/from the application locale as
necessary.

Nico
-- 

_______________________________________________
Kitten mailing list
Kitten@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten