Subject: Re: Updated I18N proposal

From: Simon Josefsson <[email-masked]>
Date: Thu, 11 May 2006 17:16:46 +0200

I'm jumping in late, ignoring the first proposal...

Nicolas Williams <[email-masked]> writes:

> 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()

Given that running code implement these differently, that seem like a
good idea.

>  - 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)

Given that Unicode and UTF-8 is the natural choice for i18n of IETF
protocols, this also seem like a good idea to me.

On the names: What about GSS_Import_name2 and gss_import_name2
instead?  Then the naming style between bindings will be more
consistent.

>  - 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.

Why would those be provided?  I see two distinct reasons:

1) To provide backwards compatibility for applications that assumed
   GSS-API handled data in locale encodings.

2) To provide new APIs to make it easier for application, so
   applications can avoid to convert from locales to UTF-8 internally.

I don't think 1) is a good idea, it seems better to use the original
function names for backwards compatibility.

2) may be a good idea, in LibIDN I provide both UTF-8 and locale APIs
for application that want to do stringprep, and the locale APIs are
often used.

>  - 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 agree.

> 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.

I'd be happy too.

Thanks,
Simon

_______________________________________________
Kitten mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/kitten

---

From: Nicolas Williams <[email-masked]>
Date: Sun, 4 Jun 2006 23:54:17 -0500

> instead?  Then the naming style between bindings will be more

We decided at some point that only the C bindings will get these.

>    applications can avoid to convert from locales to UTF-8 internally.

(2).

Basically, some of us would end up writing utility functions that amount
to having these *_locale() functions around.

> for application that want to do stringprep, and the locale APIs are

(2) is a good idea because it reduces code duplication.

Nico
--