[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: "Last Look" at the RADIUS Design Guidelines document
So here is the thread
> On 14-01-2010, at 11:16 , Alan DeKok wrote:
>> Your suggestion is *denying* the possibility that RADIUS servers can
>> process complex attributes themselves. Some people have servers that
>> are capable of encoding and decoding complex types without resorting to
>> adding application layers.
In response I wrote....
> Because according to you, a RADIUS server can be constructed that can encode and decode complex types without resorting to adding application layers and presumably even new code. The paragraph is thus misleading and should be fixed or removed.
Your response to the above....
That statement is simply not true under any objective definition of reality.
(Avi) but Alan I am paraphresing your own statement
> I don't see how. I said red, you say blue. There's a teensy
> difference between the two.
(avi) and now you are saying that that is not what you said????
> I'm saying your paraphrasing doesn't match my words. In fact, it's
> nearly the opposite of what I said.
I dont know but I think this accurately reflects the conversation.
In any case.... you continued ....and I want to repsond to you.
> The confusion here seems to be that you appear to believe:
> "complex attributes" == "external application processing of data".
No not at all.
> This is not true.
> As my earlier messages said, many implementations
> can process complex data themselves, and don't need external
> applications to do that for them.
> This goes back to the root cause of the disagreement: The document
> explains one model of RADIUS. You are arguing that this model is no
> longer applicable. You want to *require* a newer model.
No the issue is that the document does not explain this model -- and I want it to. In fact it says the opposite. And once again I will put in the paragraph that is the offending paragraph....It needs to reflect the statement that complex types can also be handled by these RADIUS server without code change.
One of the fundamental goals of the RADIUS protocol design was to
allow RADIUS servers to be configured to support new attributes
without requiring server code changes. RADIUS server implementations
typically provide support for basic data types, and define attributes
in a data dictionary. This architecture enables a new attribute to
be supported by the addition of a dictionary entry, without requiring
RADIUS server code changes.
You can simply add something like this to the end of that paragraph:
Complex attributes may also be added to the dictionary such that the RADIUS server does not require code changes to process these attributes.
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.