[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: no overall type in Extended Attributes
Glen Zorn wrote:
> No, I said that I want to name an attribute that consists of a group of
> TLVs, not the same thing.
Hmm... the number space for the Extended-Types is flat. So one
attribute cannot "consist of" a group of TLV's.
> For example: a cryptosuite consists of a an
> encryption algorithm identifier and an integrity-protection algorithm
> identifier. Multiple cryptosuite attributes can be in the same message.
> Both the integrity-protection and encryption algorithms MUST be present or
> the cryptosystem attribute is malformed. I know how to do this easily & in
> a way that comprehensible in Diameter or w/a legacy RADIUS attribute.
Diameter has a "group" attribute, which is easy. I don't know how to
do this with a legacy attribute, other than via a complex type.
> Apparently it is not possible to specify such a thing in an easily
> comprehensible fashion using Extended Attributes. I consider this to be a
> problem (now -- I didn't before because I hadn't run into this,
> short-sighted, I know); I'm not sure why (given your sympathetic concern for
> programmers who would separate the word "hello" into 5 different attributes
> ;-) do not.
I don't see a problem with sub-TLV's, like is done for WiMAX. The
various vendors will be implementing WiMAX anyways, so adding sub-TLV's
here wouldn't be a problem.
This would involve extending the RADIUS data model to include a "tlv"
type. If the format is the normal 8-bit type, 8-bit data, it would be
compatible with the WiMAX definition, the 3GPP definitions, and perhaps
some other vendor-specific definitions.
to unsubscribe send a message to email@example.com with
the word 'unsubscribe' in a single line as the message text body.