Issue: 2486bis internationalization and unassigned codepoints

[Jari Arkko <jari.arkko@piuha.net>]

At IETF-62, this presentation outlined the i18n issue:

http://www.drizzle.com/~aboba/IETF62/radext/ietf62_radext_nai.ppt

Subproblems 1 and 2 are OK. Subproblems 3 and 4 are still open.

3 is really about what to do with unassigned codepoints. My current
thinking is that  a username with a particular character X will not be 
entered
into the Radius server's database unless X is supported the
Unicode and software versions of the server's admin UI.
The same for the client end and user's UI. Therefore, I think
what we need to say is that the all the i18n mapping and
checking operations happen only at the client (when entering
a NAI), and when entering this particular user's subscription
at the server side. And nothing in between should do this
under normal circumstances, they should just be passing
bytes along, not checking whether those bytes form unassigned
or assigned code points.  This ensures that an old proxy doesn't
prevent your new username from being used.

Does this work for everyone?

--Jari


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