"Also sprach Alan DeKok:"
> "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
No I am not. I am thinking
x = 1
where x is "Whatever-It-Is" and 1 is "PPP", in this case.
> variable, and values is the value of the variable."
I have no idea why you think that is not what I am thinking of! It is
perfectly simple: PPP is written in all caps. That makes it a literal
constant in almost all languages known to mankind. What's more, it IS a
literal constant! PPP IS the name of a well known portocol. You would
get the same instinctive response out of me if you wrote
Person = PETER
!!
> I can honestly say in nearly a decade of RADIUS work, this is the
> first time I've seen someone make that confusion.
What confusion? I really don't see why you don't see it .. You write
somthing that looks like "x = 1" and now ask me to believe that "1" is a
variable?
> > OTOH you have things that are obviously field names, because they
> > contain "-".
>
> Your assumptions are incorrect. The "-" character is just another
I am not assuming anything, I am _telling_ you that about the only place
anyone uses - signs in identifiers is in cobol and jcl record field
names, and other languages which share portions of the same evolutionary
history.
> character, and has no special meaning of "field name".
Oh yes it does. I'm afraid the rest of the universe disagrees with you!
We use conventions for a reasonm, no?
> I have no idea
> why you think it means a field name, but it doesn't mean that in
> RADIUS.
Will you PLEASE step outside of the tiny universe you have built for
youself, in which some things are upside down, and instead COMMUNICATE?
Communication involves using a standard language, with standard
semantics. If you don't don't use it, YOU are in the wrong, not the
rest of the universe.
To the rest of the universe, Foo-Bar-Gum is a field name, and I see no
reason to suppose from what you say that that is not its semantics here!
Field name is a perfectly good name for it! What else are you
suggesting it is? Does it not appear in the records that are send to
and fro by the protocol? Does it not bind a value at runtime? Well,
then it is a field name.
> > 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.
I don't know know what you mean. But ONE of us is the author of several
languages, and the other is not.
> > 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*.
Will you please stop using that word? They are TERMs! Just as they have
always been in computing languages. Your terms may be either literal
constants or variables, it appears. That's fine. Now please stop
calling them "values"! That you don't define what you mean by "value"
is part of the trouble! It's a meaningless word as you use it. To the
rest of the universe, a value is what you find as an element of a
domain. The domain of real numbers has values that are real numbers. A
variable that ranges across the domain of reals will have value that is
a real number, etc.
I suspect that your computational domain is "strings". I suspect that
the TERMS on the right hand side of your = signs may be either literal
constants with VALUE a string, or VARIABLES with VALUE a string. Or
compund terms.
There's no need for mystery! It just takes a simple yes or no from you.
But if you were to explain yourself clearly then you would save other
people hours of time.
> They may be pre-defined
> names, numbers, fixed strings, or references to variables. But they
> are NOT variables in and of themselves.
And nobody said they were. Unless you want to redefine "is"! Because A
IS a B does not imply that B IS an A! That PPP is a variable does not
imply that whatever is on the rhs of an == must be a variable, just as
I said, as you can read above.
> > However, all my experiments failed to confirm that.
>
> Because it's not true.
It is true, according to what the docs eem to say and other participants
in this thread. Are you suggesting that PPP is instead a constant (as I
believed)? Not that I am interested, but here is what your docs say:
DEFAULT Service-Type == Framed-User, Framed-Protocol == PPP
Service-Type = Framed-User,
Framed-Protocol = PPP,
Fall-Through = Yes
If the request packet contains the attributes Service-Type and
Framed-Protocol, with the given values, then include those attributes
in the reply.
See that Framed-Protocol is a FIELD! It says so: "If the request packet
contains the attributes .." (attribute is another name for a field of a
record). The right hand side (PPP) of the == must then either be
another attribute (field name) or a constant or a newly introduced
variable. It cannot be another field name, surely? There is no
reference to "PPP" on the left anywhere in your examples. It must
therefore be a constant or a newly introduced variable.
I chose to believe that it is a constant, because it is lexically
distinct from what I expect a variable name to look like. I expect
variable names in lower case, always - "ppp" would be a variable. And
PPP looks like a constant! It is the name of a well known protocol.
However another responder has said that it is a variable. Well, that's
fine by me. I can read A-B-C == FOO as an assignment to FOO if I really
want to. But my experiments have indicated that it is not - that it IS
a literal constant.
So what distinguishes literal constants from field names in your
language? Not the "-" signs, you have said!
> > What I finally had success with was
> >
> >
> > foo bar =~ "^(.+)"
> > gum = `%{0}`
>
> Exactly. The string in "gum"
There is no string in gum. The value of the FIELD (or variable, if
you like to call it that) "gum" is that assigned to it on the right,
which is achived by evaluating a perl expression that makes reference to
an environment that is populated via the =~ expression.
I imagine your implementation actually works by putting a special
"flagged string" into gum near initialization time, and then
reinterprets it on the fly when it encounters the string in various
context, such as when it has to do operations on it.
Thats fine, but it just means that your implementation is partially
interpreted. Nothing wrong with that. It has to be done by late
interpretation. It's an implementation fact.
> is a reference to a variable. It is
> not itself a variable. "gum" is the name of a variable.
Puhleeeeeze. Nobody is claiming that it is a variable. It is a term.
Terms may be many things, including constants, variable dereferences,
or references, and compounds. In this case it is a compound expression.
There is an environment dereference (%{0}) and an interpretation
imperative (` `).
> Have you *ever* done any programming? I have no idea why you would
> make this elementary mistake.
:-). If you would cease insulting, you would come to understand that
you are talking from within a very small and very tight brown paper bag
which may perhaps fit a little too tightly ..
> > 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.
I am not :-)! That would be funny.
> The RFC's are the specification
> of RADIUS, they define attribute names and values.
I am sure they define many things. The point is that your documentation
does not define what IT is talking about, and therefore fails, as
documentation for users.
> The FreeRADIUS
> manuals describe one implementation of RADIUS, they reference the
> RFC's.
No they don't. No manual should "reference an RFC", except in a footnote
at the end! It's YOUR business to deal with the RFC, not ours! You are
supplying the implementation, therefore we need to know how to deal
with your tool, not how to deal with the RFC.
> 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.
No - I am expecting you to behave less like a hot headed obstinate dummy
and more like the intelligent human being that I expect and fully
believe that you are. If *I* say that your documentation is
incomprehensible in parts, it *is*. It is not a question of disputing
it, it is a question of fixing it there and there and saying, oh,
thanks, we didn't realise that we were talking about things backwards
with respect to the rest of the universe there. OK.
No muss, no fuss.
> It's a ridiculous attitude, and doubly so because the "doc"
> directory in FreeRADIUS contains the RFC's.
I have no idea what it contains, since I have not looked. Are you
seriously suggesting that I should take some hours (well minutes)
out of my life to make up for the lack of explanation in your docs?
Which by the way, are very well explained and commented generally, but
just have this little problem that they are written in jargon in parts,
backwards, by a person who has apparently forgotten that the rest of
the universe uses the standard semantics, not the inverted ones you may
well be using for all I can tell!
> > 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.
They it can cease so assuming, because that makes it useless. If you
doubt it, try reading a text on supersymmetry without explaining that
when they write "->", they actually mean "<-".
> It doesn't try to refute
> every readers pre-defined notions about "field names", because that
> would involve writing infinite amounts of documentation.
No, it would involve you expressing yourself in standard notation and
in terms of standard concepts, and using words in the way they are
universally accepted. I don't know why you think that in
A-B-C = FOO
FOO is neither a variable nor a constant, but everyone else thinks that
your documentation says it is one or the other, your examples seem to
show that it is, and if you mean that it is only ever the literal
constant "FOO", then the rest of us would like to know what difference
there is in the name that makes it so! Would writing it "F-O-O" make it
suddenly into a variable instead of a constant?
Or is it that on the rhs of an =, the same syntactic terms have a
different semantics than on the lhs? That's fine, but we need to be
told! On the left they are clearly names of variables. On the right they
are constants?
> > > 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".
I am not confused, thank you, you are. And the reason is probably that
you have been working with radius for a decade.
> > 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".
You don't need permission. The value of a constant is a value. It
cannot be anything else! Perhaps you are confused between the syntax
and the semantics? The syntax dictates what you may write. The
semantics dictates the interpretation of the syntax, its "value".
The question here is what is the SYNTAX alowed on the right of an =
sign. I have said that conventionally it is what is called a TERM.
TERMs are syntactic constructs that may usally be either literal
constants or variable names or compounds using other operators. The
semantics of such a term will be that radius at run time INTERPRETS it
as a VALUE from the DOMAIN of possible values.
Clearer now?
> But your assertion that the RHS can be a variable is simply wrong.
Then why do your examples seem to say it is the case? My experiment
seems to show that the rhs of a = sign is a constant, which has a value
of course, when it is interpreted by radius. But your examples in the
docs seem to show the opposite.
I interpreted PPP as a constant. You seem to be saying it is not:
variable", when you should be thinking "attribute name = name of
variable, and values is the value of the variable."
See? According to you, PPP is a variable!
> > > $ 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.
Then why is it showing a different reply below?
Because it is NOT saying "I sent no response" here! It should.
> > 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.
It is YOU that have the problem. There are a few incorrect "correct
names for things" in radius, as far as I can see. That's the problem!
> 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.
Will you please cease these insults? If you want to live in a small
topsy-turvy world, that's fine by me, but it isn't the place the rest
of the world is living in! All you have to do is make your documents
unsderstandable by people who have the ordinary understanding and
conventions of the rest of the world in their head! They're not far
off! They're nice docs. I like them! That nobody can easily work out
what parts of them mean is a cause for rejoicing, because you can
IMPROVE them. If they were worse (like gnu-radius, maybe), people would
not even get that far.
Peter
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
