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

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



Bernard,

This seems to work.

John

> -----Original Message-----
> From: owner-radiusext@ops.ietf.org
> [mailto:owner-radiusext@ops.ietf.org]On Behalf Of ext Bernard Aboba
> Sent: 09 July, 2005 21:09
> To: Eronen Pasi (Nokia-NRC/Helsinki)
> Cc: paul.hoffman@vpnc.org; hardie@qualcomm.com; paf@cisco.com;
> radiusext@ops.ietf.org; aland@ox.org; Jari Arkko
> Subject: RE: RFC 2486bis issue: "Decorated" NAIs and IDN support
> 
> 
> The ABNF in Section 2.1 doesn't seem to take this into 
> account, so I think
> that a change may be needed there too.   For example, to 
> allow NAIs such
> as
> 
> other2.example.net!home.example.net!user@other1.example.net
> 
> I think you need a rule like:
> 
>    nai         =  username
>    nai         =/ "@" realm
>    nai         =/ *(realm "!") username "@" realm
> 
> 
> 
> On Fri, 8 Jul 2005 Pasi.Eronen@nokia.com wrote:
> 
> >
> > 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/>
> 

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