RE: Data Types defined in RFC 2865

["Glen Zorn" <glenzorn@comcast.net>]

Bernard Aboba [mailto://Bernard_aboba@hotmail.com] writes:

> "  It goes on to name the five data types, and give definitions for
> each
> one.  These data types are then used in the attribute definitions in
> RFC
> 2865, and in other RADIUS RFCs."
> 
> Section 5 is unambiguous on this point:
> 
> "     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.
> "
> 
> Moreover, within the value field of each attribute, RFC 2865 includes
> the
> data type:
> 
> a. "String" for type string.
> b. "Address" for type address

Is a netmask considered an address?

> c. "Value" for type integer

Wow, I am really amazed!  I don't know how many times I've read that RFC &
never noticed the apparently 1-1 correlation between naming the "Value"
field of an attribute "Value" and the contents of that field being an
integer (though with special "flag" values sometimes).  I'm really very
impressed, but does that really qualify as "unambiguous"?

> d. "Text" for type text
> 
> No attributes of type time are defined in RFC 2865 or 2866.
> 
> Looking at other RADIUS RFCs, the inclusion of the data type within the
> value field is less consistent.
> 
> For example, RFC 2867, includes a type of "Lost" in Section 4.2 for
> Acct-Tunnel-Packets-Lost (4 octets).  It seems likely that this
> attribute
> was intended as type integer, rather than a "lost" data type.

Actually, it seems much more likely to me that the field was named
descriptively (I know it's insane, but then Alan DeKok wasn't around to show
us the True Way ;-).  Additionally, in 2866, the "Value" field of the
Acct-Multi-Session-Id attribute is named "String", but its contents are
specified as UTF-8 encoded 10646 characters (the definition of the "text"
type).

> 
> In RFC 2869, the term "Value" is used in the value field for attributes
> that
> are not integers (e.g. ARAP-Challenge-Response in Section 5.15).
> 
> RFC 3162 seems closer to the conventions of RFC 2865 & 2866, although
> the
> "Address" type used is 16 rather than 4 octets in size (IPv6 vs. IPv4).

So am I to understand that, despite the multitude of counterexamples and the
lack of any explicit text even suggesting such in any RADIUS-related RFC,
you are claiming that the name of the V field in the TLV construct denotes a
formal data type (a thing apparently known only to some secret society
holding the same "internally consistent belief system" (thought police,
anyone? ;-)?

...


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