RE: Issue: Treatment of null Identity Response

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

Bernard Aboba writes...

> Since RFC 4282 discourages use of pseudonyms such as "anonymous"
> it is not clear what the preferred representation is for "the 
> anonymous user of the local realm".  Under this line of thought,
> the null userid might not only be legal, it might actually
> be the *preferred* representation!

Well, yes, but...  RFC 2865 defines the value field of attributes as
follows:

<quote>

      The format of the value field is one of five data types.  Note
      that type "text" is a subset of type "string".

      text      1-253 octets containing UTF-8 encoded 10646 [7]
                characters.  Text of length zero (0) MUST NOT be sent;
                omit the entire attribute instead.

      string    1-253 octets containing binary data (values 0 through
                255 decimal, inclusive).  Strings of length zero (0)
                MUST NOT be sent; omit the entire attribute instead.

      address   32 bit value, most significant octet first.

      integer   32 bit unsigned value, most significant octet first.

      time      32 bit unsigned value, most significant octet first --
                seconds since 00:00:00 UTC, January 1, 1970.  The
                standard Attributes do not use this data type but it is
                presented here for possible use in future attributes.

</quote>

For text and string types, RFC 2865 indicates that zero-length binary or
text strings MUST NOT be sent in attributes.  So it would seem to be a
conflict with RFC 2865 to require NULL strings.


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