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

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