As long as the compound format made sense for the actual entity generating or processing the attribute's contents and as long as the individual member values were not needed in any RADIUS policy nor generated dynamically by the RADIUS server proper, there's never been a strong problem with such compound attributes, and I don't think there necessarily should be any such problem now.
I think this is a very reasonable distinction. If there is no need to distinguish the member values, compound attributes are ok. However, if there is such a need, compounding is problematic, requiring code to be written that would not otherwise be necessary. Reducing the need for continual code updates was the original purpose of the Dictionary, after all.
-- 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/>