Subject: Re: [Ietf-krb-wg] Kerberos V5 Internationalization of Error Messages

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 09 Jan 2008 08:57:59 -0500

--On Friday, December 21, 2007 09:57:48 AM +0100 Simon Josefsson 
<[email-masked]> wrote:

> All,
>
> to get some krb5-i18n discussions going, I wrote the document below.
> The document is currently only about KRB-ERROR.  I believe this is the
> simplest part of the bigger i18n problem, and attacking the problems one
> at a time may reduce the perceived complexity of the final solution.
>
> Is anyone interested in helping with this document?  I would appreciate
> feedback and comments.

You should actually submit that to the internet-drafts repository, rather 
than including it inline in a message to the list.  For many of us, drafts 
that are actually in the repository are _much_ easier to find in our local 
mirrors. :-)

Note that these days it is very quick and easy to get an I-D published 
(just submit via the web), and as always, it is entirely appropriate to 
submit an I-D as a strawman or as the subject of a proposal you plan to 
make to one or another WG.

I think working on the i18n issues piecemeal is fine, to a point, if it 
helps us get where we need to be.  I'd be a little concerned if doing so 
results in complex negotiations involving many round trips and 
combinatorially exploding variations that every implementation has to deal 
with.

-- Jeff
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 09 Jan 2008 16:15:35 +0100

> make to one or another WG.

Right, done.

> combinatorially exploding variations that every implementation has to deal 

I agree.  I think my choices to depend on RFC 4646 language tags and the
changes to ASN.1 are worthwhile to discuss regardless of how the
signalling mechanism to enable i18n will work.

There are several alternative ASN.1 changes that could be chosen
instead.  I expect that some may frown upon changing the APPLICATION
tag, which I chose as an initial strawman.  But if those concerns are
articulated, that's progress.

Btw, I have struggled with the KRB-WG charter text that says the i18n
solution need to be "backwards compatible".  I'm not sure if it is
possible to meet that goal and come up with a good design.

I believe you must upgrade implementations -- possibly all of clients,
servers and KDCs -- to get usable i18n support.

Is the intention with the charter that we should try to minimize the
breakage when either the client, server, and/or KDC, do not support the
new i18n solution?

Or is the intention that i18n should work even though some of the
client, server, and/or KDC do not support the new i18n solution?

Or whether there should be smooth downgrade to the pre-i18n situation
when a non-i18n implementation is discovered?

It would be easier to produce a good i18n solution if we can assume that
clients, servers and KDCs must be upgraded.

/Simon