[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RFC 2486bis issue: "Decorated" NAIs and IDN support
> I am lost here. An IDN client (in this case, the UI where the user
> enters the NAI), is responsible for doing a Unicode-to-ASCII
> conversion. It becomes a valid FQDN right there. The only tricky part
> is that the UI has to look for DNS names amid the ! and @ characters.
>
> >Can you look at the below thread and give us your feedback on how
> >we should think about this?
>
> See above. The thread you passed bounced around among many proposals.
> Basically, something needs to find the domain names in the string
> that the user entered and convert them to ASCII. And domain names
> (even in the middle of the other gunk in the NAI) being displayed
> should be converted back to UTF-8.
OK. So if I understand this correctly then:
a. It is the responsibility of the peer to provide the NAI in the
correct (ASCII) format.
b. Similarly, it is the responsbility of the RADIUS proxy to provide its
realm table entries in the same ASCII format.
c. Assuming a) and b) are done, then the proxy does not need to do any
conversions in the manipulation of "decorated" NAIs. For example, it can
convert microsoft.com!bernarda@bt.com -> bernarda@microsoft.com without
having to "translate" microsoft.com (assuming that this contained only
appropriately formatted ASCII characters).
If a DNS lookup needs to be done (not required in RADIUS but potentially
needed in Diameter) then the proxy can use the realm directly without
conversion.
Is this right?
--
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/>