RE: RFC 2486bis issue: "Decorated" NAIs and IDN support

[<Pasi.Eronen@nokia.com>]

I think the approach proposed below is a good one (or at 
least I don't see any better approach either). 

It also doesn't require much changes to 2486bis; we just need 
to mention that all realm names, both after "@" and before "!" 
(when that notation are used), are IDN-unaware domain name 
slots.

Would this clarification to Section 2.7 be sufficient, or do
we need more text?
OLD:
   In this case, the part before the (non-escaped) '!' MUST be a
   realm name as defined in the ABNF in Section 2.1.  When
   receiving such an NAI, ...
NEW:
   In this case, the part before the (non-escaped) '!' MUST be a
   realm name as defined in the ABNF in Section 2.1.  This realm
   name is an "IDN-unaware domain name slot", just like the
   realm name after the "@" character; see Section 2.4 for
   details.  When receiving such an NAI, ...

Best regards,
Pasi

> -----Original Message-----
> From: Bernard Aboba
> Sent: Sunday, July 03, 2005 11:52 PM
> To: Paul Hoffman
> Cc: hardie@qualcomm.com; paf@cisco.com; radiusext@ops.ietf.org
> Subject: 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/>