Hi,
Alan D or Stefan W should be able to comment on half implementations of 'SHOULDS' and whether they're compliant or not.
The thread unveiled two issues: * values with a length "near" 253 characters might cause undesired behaviour * several instances of Class are ignored; only the first instance is returned For the former case, this would be clearly a bug. The RFC very clearly states that the data type is String, which can be up to 253 bytes. Not delivering this in the product IMHO means it is violating the spec outright. For the latter issue, a "SHOULD" and its equivalent "RECOMMENDED" has a well-defined meaning in theory (" SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. ") [RFC 2119, section 3.3] but in practice this just means "Ignore it if you want" (because there are always some "particular circumstances" if you need an excuse). So when the client receives N Class attributes, yes, it SHOULD send them all back, but if it doesn't, too bad. Greetings, Stefan
Annoyingly the RFC doesn't provide an upper bound, and that might be why they only chose to store a single attribute given the extremely memory constrained environment code is running in.
Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66