Re: Closing the NAIbis i18n discussion

[Bernard Aboba <aboba@internaut.com>]

I think this makes sense.  Perhaps you should cite RFC 3490 in the
document, to make it clear why this approach was taken.

Am I correct in saying that the recommended approach implies that RADIUS
proxies don't have to do any character set translations when processing
"decorated" NAIs?  If so, that is a good thing.

Question: does this have implications for EAP peer implementations that
just send UTF-8 in the EAP-Response Identity?  I think it doesn't imply
that they should check that the realm part is compatible with the
"IDN-unaware domain name slot" grammar, but I wanted to check.

On Mon, 20 Jun 2005, Jari Arkko wrote:

> Hello folks,
>
> We need to close this and move ahead. It seems that
> we have consensus to do as little as possible, though
> opinions differ as to what that exactly means :-)
>
> I'd like to go with UTF-8 usernames + plain old DNS
> names for the realm part, which was also supported
> by Alan's e-mail quoted at the end of this message.
> This seems to work most of the time, and is also
> according to the MUSTs in RFC 3490:
>
>    An "IDN-unaware domain name slot" is defined in this document to be
>    any domain name slot that is not an IDN-aware domain name slot.
>    Obviously, this includes any domain name slot whose specification
>    predates IDNA.
>
> That is, our NAIs are IDN-unaware name slots, because
> 2486 < 3490 ;-)
>
>    2) Whenever a domain name is put into an IDN-unaware domain name slot
>       (see section 2), it MUST contain only ASCII characters.
>
> That is, RFC 3490 requires us to do this...
>
> If the rest of you agree then I will submit the document in a couple
> of days and we can move on. Otherwise, let me know what I should
> put in.
>
> --Jari
>
> Alan DeKok wrote:
>
> >Jari Arkko <jari.arkko@piuha.net> wrote:
> >
> >
> >>> Years of deployment without complaints is a strong indicator that a
> >>>problem doesn't exist.  Let's let sleeping dogs lie.
> >>>
> >>>
> >>>
> >>Ok. But I'd still like to understand this better. Or I really
> >>need to, because we need to decide whether to
> >>  (a) strip i18n out of the bis draft altogether
> >>  (b) keep current utf-8 + plain-old-dns-name-but-as-idnunaware-
> >>        name-slot scheme
> >>  (c) change to utf-8 altogether
> >
> >  I would say (b).
> >
> >>Also, before you answer the above lets try to get some
> >>understanding on whether "no complaints" means
> >>  (i) no one is using i18n dns names yet. i have some sense
> >>      that this might be the case, as at least here in Finland
> >>      I think they allowed the new types of allocations
> >>      very recently.
>
> >  Mosrly.  i18n domain names have historically been rare.
> >
> >>  (ii) existing support (just let utf-8 through) is working
> >>       well
> >
> >  Definitely.
> >
> >>  (iii) solutions from a single vendor work well, but
> >>        not a lot of interop has been attempted with this
> >>        particular case
> >
> >  I would say that interoperability hasn't been *reported* on.  But
> >the deployments of RADIUS are so varied that I would be surprised if
> >interoperability isn't already being tested in live situations.
> >
> >  I haven't heard of i18n problems with interoperability.  My guess,
> >therefore, is that such problems are rare.
> >
> >  Alan DeKok.
> >

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>