Glen Zorn writes...
> > As a result, the introduction of new complex data types within
> > RADIUS attribute specifications SHOULD be avoided, except
> > in the case of complex attributes involving authentication or
> > security functionality.
>
> All of the attributes are security related.
Yeah. I've always been a bit uncomfortable with the "security functionality" escape clause in the RADIUS Design Guidelines draft. Lots of things can reasonably be claimed to be "security related". I would have preferred the exception to be crafted a bit narrower, just for this reason. But, unless wording of Design Guidelines is changed, you have a legitimate argument.
> > I do not see any pressing need to make this attribute carry seven
> > independent fields. The RADIUS attribute space has sufficient room to
> > allocate 7 attributes. If the extended attribute format is used, then
> > nearly all space limitations are removed. I would recommend that these
> > independent values be split up into independent attributes that follow
> > the RADIUS data model.
>
> Given that there are already multiple interoperable implementations and all
> of the attributes are security related, I see no pressing need to make
> people change running code to satisfy your personal preferences. Sorry if
> these attributes were designed to be easy to implement for people writing
> PKM code, rather than RADIUS code.
No one has ever claimed that following the RADIUS Design Guidelines is the only way to interoperable implementations. Lots of designs, good, bad and indifferent, can be made to interoperate.
If we are to dismiss the Design Guidelines as a "personal preference" how are they to be taken seriously? I understand that following someone else's design guidance is not always popular with developers, but following regular design patterns is a well recognized practice in software engineering, that is generally attributed with increasing product quality and maintainability. I think we simply need to "get with the program" here.