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 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html