dictionary: override attribute type/id mapping

[Andriy Gapon]

Alan,

thank you very much for your reply. Sorry if my reply breaks message
threading for you - I am replying based on the web-archive as I don't
receive this list by email.
I also want to apologize if my tone seemed too attacking towards
freeradius for such a novice that I am.

I want to "restart" this discussion while providing some minor
comment/replies to your answer.

Now to the subject matter: let us imagine some not very distant future
when digest authentication extension is finally standardized, there is
an RFC for it, there are devices/software that implement it. FreeRADIUS
obviously also wants to support this RFC-digest-extension. On the other
hand there are still many devices out there that use
draft-sterman-aaa-sip-00.txt and FreeRADIUS obviously wants to continue
to support them as well. In both cases people would probably like to use
"Digest-Response" attribute name (and other digest attribute names), so
that it refers to a correct attribute for their configuration.
I thought about this a little bit and I think that either some new names
would have to be introduces (e.g. "Digest-Response-New" or
"Digest-Response-Old") or somehow separate dictionaries would have to be
created and users would have to be careful about using them.
How would you resolve such situation ? Maybe I am totally missing some
other possibilities ? Are there any precedents ?

And some comments below:

Alan DeKok wrote:
> Andriy Gapon <avg at icyb.net.ua> wrote:
>> Shouldn't I be able to override name->number mapping for attributes ?
> 
>   Yes, so long as the only thing different is the name.
> 
> ATTRIBUTE Foo-Bar 10 ipaddr
> ATTRIBUTE Bar-Foo 10 ipaddr
> 
>   is OK.
> 
> ATTRIBUTE Foo-Bar 10 ipaddr
> ATTRIBUTE Bar-Foo 10 string
> 
>   is not OK.

I wanted (or, at least, I thought that I wanted) something a little bit
different - not a new name for the same type, but a different type for
the same name. E.g.:
$ cat /usr/local/etc/raddb/dictionary
ATTRIBUTE       My-Local-String         300     string
ATTRIBUTE       My-Local-String         301     string
$ radiusd -sfxxyz -l stdout
...
 main: debug_level = 0
read_config_files:  reading dictionary
Errors reading dictionary: dict_init:
/usr/local/etc/raddb/dictionary[2]: dict_addattr: Duplicate attribute
name My-Local-String
Errors reading radiusd.con

> 
[skipped]
>   Please *read* the attribute definitions.  The definitions in
> dictionary are RADIUS attributes that go over the wire.  The ones in
> dictionary.freeradius.internal are not.

Yes, but they can still create some confusion - dict_attrbyname() will
still see them. But this is not important.

>>  Especially given that those definitions are based on the very old
>> and expired draft and are very unlikely to become standard.
> 
>   Standards matter less thyan interoperability.  There are many
> systems deployed with the current digest attributes.  Changing them
> now is not an option.

Completely agreed, but I am rather talking about moving them into a
separate file (BTW, there already seems to be "dictionary.digest")
instead of having them directly in "dictionary".

>> I think that those definitions should be clearly separated into
>> their own dictionary
> 
>   Once a standard is published for digest, the attributes in that
> standard will be placed in their own dictionary.
> 
>> and they should also somehow be marked as based on the
>> draft-sterman-aaa-sip-00.txt
> 
>   The ones in "dictionary" are marked as being based on that draft.

By "marked" I meant not a mere comment in a dictionary file, but some
prefix to their name or something like that, e.g.
"PreRFC-Digest-Response". But this is probably too intrusive to do now.

>
[skipped]
>

-- 
Andriy Gapon