RE: Issue: Treatment of null Identity Response

["Nelson, David" <dnelson@enterasys.com>]

Jari Arkko writes...
 
> >The text in the CUI draft indicates that the NUL CUI includes a
single
> >'NUL' character.
>
> Right. This is correct, and we do not have a problem with the empty
> string rule.

Since counted strings can have embedded NUL characters, that's true.  It
obviously requires special handling in the C-style string to RADIUS
string conversion, though.

> >I recall that representation originates from Diameter specs. As at
some
> >early phases of the CUI there was direct linkage to Diameter CC
> >Subscription-Id-data, which is defined as UTF8String. A definition
for
> >UTF8String is in RFC3588 (using UTF-8 transformation format as
described
> >in RFC2279) -- not in RADIUS RFCs though.
> >
> I would prefer fixing the type to a RADIUS type (string).

I agree, although if the type is intended to be a UTF-8 printable
string, the correct RADIUS type would be "text", not "string.  If there
is consensus on that, it could be fixed in AUTH48.

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