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