"Peter T. Breuer" <[EMAIL PROTECTED]> wrote:
> Because the other is in capital letters, called PPP, and does not begin
> with an "x" or contain a "-", all things which would indicate
> variables. It looks like a constant. PPP. If it is a variable, then it
> does not look like one. It's the name of a well known protocol.
Ah. That's why you're confused. You're thinking "value ==
variable", when you should be thinking "attribute name = name of
variable, and values is the value of the variable."
I can honestly say in nearly a decade of RADIUS work, this is the
first time I've seen someone make that confusion.
> OTOH you have things that are obviously field names, because they
> contain "-".
Your assumptions are incorrect. The "-" character is just another
character, and has no special meaning of "field name". I have no idea
why you think it means a field name, but it doesn't mean that in
RADIUS.
> Field names have been used forever as variables. They
> are pointers to a value - i.e., variables. When you read
> "Colour-Spectrum" you do not expect it to mean the string "Colour-Spectrum",
> but instead a vector of real numbers.
Your expectations are wrong. Please correct them.
> In this case, now I have a little experience, I GUESS:
>
> Values on the rhs of an = may be either constants (strings in quotes)
> or variables (names which have been introduced before that point on
> the rhs of an ==).
Your guess is wrong. The values on the RHS are not variables, and
cannot be variables. They are *values*. They may be pre-defined
names, numbers, fixed strings, or references to variables. But they
are NOT variables in and of themselves.
> However, all my experiments failed to confirm that.
Because it's not true.
> What I finally had success with was
>
>
> foo bar =~ "^(.+)"
> gum = `%{0}`
Exactly. The string in "gum" is a reference to a variable. It is
not itself a variable. "gum" is the name of a variable.
Have you *ever* done any programming? I have no idea why you would
make this elementary mistake.
> Tough - if I have to read the rfc why should I read your manual page?
You're obviously confused about the difference between a
specification and an implementation. The RFC's are the specification
of RADIUS, they define attribute names and values. The FreeRADIUS
manuals describe one implementation of RADIUS, they reference the
RFC's.
Are you really telling me that you expect us to copy all of the
RFC's into the FreeRADIUS manuals, and that you refuse to read the
RFC's because they're not in the FreeRADIUS manuals? That's nonsense.
It's a ridiculous attitude, and doubly so because the "doc"
directory in FreeRADIUS contains the RFC's.
> You can jolly well define what you are talking about! Writing is about
> putting yourself in the shoes of your reader and guiding them to a
> semantic understanding that matches yours. Anything else is arrogance -
> i.e. a failure to take into account the other person.
The documentation in FreeRADIUS assumes that the reader is willing
to read the documentation and the RFC's. It doesn't try to refute
every readers pre-defined notions about "field names", because that
would involve writing infinite amounts of documentation.
> > So "Framed-Protocol =3D PPP" is referencing two things:
> > attribute, and value, both defined in the RFC's.
> ^ "variable" (not value).
> ^ respectively.
Read the RFC's. The correct term is "value". If you don't like it,
or you're unwilling to read the RFC's, I suggest you learn to deal
with the world not matching your expectations.
> If you are going to start using the term "value" to mean a "variable",
> then you are going to confuse everyone else in the world. Please stop
> this private little joke now.
In almost a decade of working with RADIUS, you are the first person
to be confused about the difference between "value" and "variable".
> The proper linguistic name for the rhs of your "=" sign is a "term",
> not surprisingly! You seem to allow terms that are either constants
> (you may call THOSE "values"!) or variables.
Well thank you ever so much for permission to call constants "values".
But your assertion that the RHS can be a variable is simply wrong.
> > $ radiusd -X
>
> It doesn't show the reply. All that shows up is:
>
> auth: type Local
> auth: user supplied User-Password matches local User-Password
> Login OK: [ptb/cacsd1] (from client localhost port 0)
> Sending Access-Accept of id 10 to 1.2.3.4:4196
> Finished request 0
It's showing the reply. If you don't understand what the reply is,
that's your problem.
> Now - I eventually managed to find out that was because there
> was NO (extra?) reply data going back.
So you don't know that RADIUS is composed of packets containing
attributes. You call it "extra" reply data.
Geez, no wonder you're confused. You're unwilling to read the
existing documentation to discover the correct names for things in
RADIUS, but you're getting upset at us for writing correct definitions
in the documentation, because it doesn't match your pre-existing ideas.
If you're unwilling to educate yourself, I suggest that you stop
reading the documentation, and stop asking questions on this list. No
one here will be able to help you if you refuse to believe their
answers.
Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
