RE: Issue: 2486bis internationalization and ! syntax

[<john.loughney@nokia.com>]

Hi Jari,

I agree with Bernard that before deciding on a solution, we need
to better understand what the current implementations are doing.

I think that 1) might be preferable, if this is more in-line with
what current proxies are doing.

John

> -----Original Message-----
> From: owner-radiusext@ops.ietf.org
> [mailto:owner-radiusext@ops.ietf.org]On Behalf Of ext Jari Arkko
> Sent: 25 April, 2005 06:26
> To: radiusext@ops.ietf.org
> Subject: Issue: 2486bis internationalization and ! syntax
> 
> 
> Issue 4 is about the interaction between internationzalition
> an the ! transformation within NAIs. Basically you may change
> 
>      user@homerealm.example.net
> 
> to
> 
>      homerealm.example.net!user@otherrealm.example.net
> 
> and back, under certain exceptional AAA routing conditions,
> i.e., when the local network can route/roam your request back
> to the right place.
> 
> Now, what makes this interesting is that the usernamepart is
> in UTF-8 and realmpart is an IDN in ASCII. Here there are
> multiple resolutions of the issue.
> 
> #1: This transformation is an exceptional case where proxies
> will perform some mapping from one character set to another.
> 
> Where such transformations are done, an attempt
> to transform a string that can't be mapped to IDN (e.g. illegal
> DNS name) should result in an error. From the user's point
> of view this would be a similar error as you get when the domain
> you are trying to give is unknown. Correct use of the this
> transformation should not result in this error, given that the
> string you put in from the '!' should have originally been a
> realm name.
> 
> One drawback of this is that in order for the proxy to map UTF-8
> to ASCII, it needs to understand the codepoints. This means in
> practise that a proxy with a today's codepoint data is unable to
> do the transformation for something that uses a newer codepoint.
> New codepoints are often defined but my understanding is that
> they are for quite special and small languages. Given this and
> the exceptional nature of the ! usage this may be acceptable.
> 
> #2: Realmpart needs to be converted to IDNA if and when a DNS
> query needs to be sent.  However, only  Diameter defines how DNS
> queries can be used to locate AAA servers; RADIUS  implementations
> do not support this.
> 
> It has been suggested that in order to "optimize for the 
> common case" that
> the entire string could be left in UTF-8, obviating the need for 
> conversions
> between UTF-8 and IDNA until a DNS query needed to be sent.  Since
> RADIUS implementations do not send such queries, they would 
> not need to
> do the conversion at all.  Within a Diameter agent,  the conversion
> could be delayed until it is required, at which time it might
> conceivably fail.
> 
> One problem with this is that existing nde that does the
> query would be unable to do a UTF-8 query but would be
> able to do an IDN query. Oh well, there isn't much Diameter
> usage that would be hit with this...
> 
> And there seems to be another more serious problem. Namely, even
> if RADIUS doesn't do DNS queries, it still stores and compares
> strings. If someone has already put in a rule or entry for an
> international DNS name, he has  been able to do so already in
> RFC 2486, because IDNs are really legal DNS names. And he
> likely didn't use UTF-8, because that would have been illegal
> as a NAI. Now, if we suddenly start sending the IDNs as UTF-8
> instead, this will break existing usage. All that is needed for
> this scenario to apply is someone who (a) has an international
> DNS name and (b) has a RADIUS server. What's the likelihood
> of this?
> 
> My conclusion: problems in approach #2 seem more likely
> to appear in common cases, so my preference is #1. What
> do others think?
> 
> --
> 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/>