[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Closing the NAIbis i18n discussion
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/>