RE: Issue: Treatment of null Identity Response

[<jouni.korhonen@teliasonera.com>]

Hi, 

The original intention was to have an UTF-8 text string. The
implementations
I know of treat the CUI as 'text' type (none of them implement the nul
CUI
yet though). However, having it defined as String type would be OK with
me
(for the reasons Jari & you pointed out).

Cheers,
	Jouni

> -----Original Message-----
> From: owner-radiusext@ops.ietf.org 
> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Nelson, David
> Sent: 15. joulukuuta 2005 17:54
> To: radiusext@ops.ietf.org
> Subject: RE: Issue: Treatment of null Identity Response
> 
> Jari Arkko writes...
> 
> > Well, if its a "string" in RADIUS terminology then its
> > really an octet string in more general terminology, and
> > implementations already have to support embedded  00s.
> 
> Agreed, but see below.
> 
> > To me the CUI function is more of a binary handle
> > than a printable string. But I'm not sure if others agree.
> 
> It is defined as a cookie, opaque to all but the issuer (home AAA
> server), so it could be a RADIUS "string" type (binary string).  I
> surmise that the reason that a UTF-8 printable string type 
> was specified
> has to do with ease of debugging (human readable characters in the
> packet trace).
> 
> I don't think it matters very much.  If it is to be UTF-8, then it
> should be a RADIUS "text" type, and if it's to be binary, we should
> remove the reference to UTF-8.

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