RE: Issue: Treatment of null Identity Response

[<jouni.korhonen@teliasonera.com>]

Hi David, 

> -----Original Message-----
> From: owner-radiusext@ops.ietf.org 
> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Nelson, David
> Sent: 13. joulukuuta 2005 21:07
> To: radiusext@ops.ietf.org
> Subject: RE: Issue: Treatment of null Identity Response
> 
> Barney Wolff writes...
> 
> > I believe the CUI was to be a single byte of 0-bits, thus NUL rather
> > than NULL and not a violation.
> 
> I don't believe so.  The intent of the "hint" flavor of CUI was not to
> change the underlying base type from printable-string to 
> binary-string.
> Sending a single byte of value zero would only be permissible for a
> binary-string and not a UTF-8 printable-string.

The text in the CUI draft indicates that the NUL CUI includes a single
'NUL' character.

"...
 For the initial authentication, the CUI attribute will include a
 single NUL character (referred to as a nul CUI).  And, during re-
 authentication, the CUI attribute will include a previously received
 ..."

> The CUI type is defined as: "The string identifies the CUI of the
> end-user and is of type UTF8String."  Of course, type 
> UTF8String is not
> a recognized data type in RFC 2865.  Can anyone point me to a formal
> definition of this, within a RADIUS RFC? 

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.


Cheers,
	Jouni

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