[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Closing the NAIbis i18n discussion

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






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