|
> A. Section 2.1.3 > > I did not find the discussion of complex attributes very compelling. > Its not clear to me what the difference between string and complex > attribute is. If your RADIUS server supports string then it seems that > it would be possible to support a complex attribute without requiring a > "code change". There are several distinct aspects that are discussed in Section 2.1.3: a. Enabling a RADIUS server to send a complex attribute; b. Enabling a RADIUS server to receive a complex attribute; c. Enabling a RADIUS client to send a complex attribute; d. Enabling a RADIUS client to receive a complex attribute. However, rather than examining each of these aspects separately, the section appears to switch between the aspects, sometimes within the same paragraph. As a result, it is not always clear what aspects are being discussed. Since the arguments made depend on what aspect is being discussed, it can be hard to follow. For example, the second paragraph of Section 2.1.3 seems to focus largely on a). As you say, in this case, a RADIUS server can send a complex attribute without a code change (merely by encoding it as a string). However, while the first bullet appears to apply to aspect a) (e.g. ease of data entry), the second and third bullets appear to relate either to aspect b) or d). On reading the second and third bullets, I'm not sure which aspect is being referred to. In paragraph 4, it is noted that RADIUS clients require code changes to support any attribute, regardless of whether it is complex or not. Therefore one cannot make an argument about additional code changes arising from aspect c) or d), only aspect b). Presumably, with respect to aspect d), a RADIUS client receiving a complex attribute would also implement the required parsing and validation routes for that attribute (if not, then the client would either ignore the attribute, or possibly reject the Access-Response). So on reading this, I'm not sure that the "additional error checking" applies to, exactly. In reading paragraph 3 about server code changes, there does not appear to be a distinction between aspect a (in which code changes are not required) and aspect b (in which a code change would be necessary). Paragraph 4 does make the distinction between aspects c and d. However, paragraph 6 mixes aspects a) and b). Paragraph 4 seems to assert that code changes are not required for aspect a), while this paragraph does seem to say that this is possible, though it is not clear in what circumstances this would be necessary. |