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

>>>>> "Martin" == Martin Rex <martin.rex@sap.com> writes:

    Martin> Jeffrey Altman wrote:
    >>  This note announces the start of a two week working group last
    >> call for the Kitten work item "Desired Enhancements to GSSAPI
    >> Naming".
    >> http://www.ietf.org/internet-drafts/draft-ietf-kitten-gss-naming-04..txt

    Martin> One thing that hasn't be addressed, but which is probably
    Martin> an issue (in particular with the IESG...): I18N.

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

Good point.

    Martin> e.g. we do ship our application (and a particular oem
    Martin> library with a gssapi mechanism) for two native EBCDIC
    Martin> platforms (OS/390 and OS/400), and both use an EBCDIC
    Martin> codepage for the printables -- which differs from ISO
    Martin> Latin 1 even for 7-bit ASCII (IA5) characters.

    Martin> Even for language bindings that natively support Unicode
    Martin> (like Java), the use of non-ASCII characters in the
    Martin> underlying GSS-API mechanism may create interoperability
    Martin> problems, i.e. with Kerberos 5 principal names and rfc1510
    Martin> communication peers.

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

    Martin> Thoughts? Experiences?

    Martin> Has anyone else encountered I18N issues with GSS-API
    Martin> (C-Bindings) or already devised a solution?  What codepage
    Martin> does your (gss-api) implementation use or your application
    Martin> expect/use?

We have encountered issues but have not managed to solve them.

I don't think we can propose specific solutions in this draft
basically because I don't think we have them yet, and I don't want to
hold up this draft.  I do think we can add a section describing the
problem and claiming it needs to be solved.  I will post text shortly.
Assuming there are not other issues I'd prefer to last call that text
but not re last call the entire document.

--Sam

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