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

Re: Closing the NAIbis i18n discussion

Bernard Aboba wrote:

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


Yes.

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.


Well, no you are not correct :-( If the realm part is an IDN-unaware
name slot, then transformations from the username part will
have to do conversions.

On the other hand, it seems to me that conversions are
going to be necessary anyway in some circumstance, and
this choice appears to place the conversion burden on a relatively
rare function, and in a place where its known for sure that
you need to do a conversion. So I think we are picking
the lesser of two evils :-)

(If we choose UTF-8 for realm part then one might ask
if the proxies doing routing or policy lookups based on the
realm part would have to normalize realms before comparisons
and lookups; its perfectly reasonable that implementations
or even users send ASCII based versions of international
domain names.)

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.


Yes. But my understanding is that implementations that
correctly process international names will ALWAYS have
to do something to the user input that they receive, to
normalize and check it in some manner. Section 2.4 of
our draft lists the requirements for the username part
that we have now. It seems that calling routine a or b
does not matter so much for implementations. Of course
there are likely implementations that just pass input bytes
on, but this appears to be something that has be fixed
anyway.

But this is just my not-so-educated understanding of
the situation. Other thoughts?

--Jari

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