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

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

This would work for me. --Jari

Bernard Aboba wrote:

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