Hi,
> > 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?
Right. Notice however, that there are many different and sometimes
contracdicting
conventions. Would you agree that it is perfectly reasonable for a RADIUS
implementation (and its documentation) to use the conventions that are detailed
in
the RADIUS RFC and not some other arbitrary set of conventions?
> Will you PLEASE step outside of the tiny universe you have built for
> youself, in which some things are upside down, and instead COMMUNICATE?
That's what he is trying to do. However, you refuse to have a look at the
about fifty pages which exactly define the conventions to be used when talking
about RADIUS (namely the RFC). Yes, personally I also found the terminology
somewhat confusing initially, but it will certainly start to be much more
confusing
if every implementor (or even every user) starts to insist on its own
conventions.
That's a guaranteed way to make communication impossible.
> 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.
Sorry, in that case, it's YOU who is trying to use a private language unrelated
to RADIUS. The rest of the universe, when talking about RADIUS is using the
words
defined in the RADIUS RFC. You're making up your own ones based on your
"superior
intuition". Sorry, but I feel like you're trying to use PASCAL syntax and
complaining
about a C compiler rejecting stuff as invalid.
> 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!
RADIUS (i.e. the RFC) defines dozens, probably even hundreds of values which do
look like this. PPP, Framed-User, Session-Timeout, etc., all those are so called
values. And e.g. User-Name, Framed-IP-Adress, NAS-Port are so called attributes.
And the only way to find out which one is which one is to either know everything
relevant for you by heart, or to look it up in the so called dictionaries.
Yes, all this is "ugly", but it also is _very_ flexible, which obviously was a
key point to the people who invented the RADIUS protocol and wrote the RFC.
> Field name is a perfectly good name for it!
Except that no one uses it when talking about RADIUS. There are "attributes" and
"values", nothing else.
> I don't know know what you mean. But ONE of us is the author of several
> languages, and the other is not.
That probably explains why you're trying to insist on using your own language
in a context where everybody else is using the language described in the
RADIUS RFC.
> > 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!
Will YOU please accept that in RADIUS, the things on the right hand side are
called values and nothing else? That's how the inventors of the protocol choose
to name those things. Would you tell my parents (and everybody else) to please
not call me Stefan because all male kids should be named Peter? I guess not..
> That you don't define what you mean by "value"
> is part of the trouble!
Could you please have a look at the simple introduction to "the RADIUS
language",
i.e. the RFC? It's going through dozens of pages and samples to define the
meaning
of "attribute" and "value".
> It's a meaningless word as you use it.
It's well defined in the context of RADIUS (contrary to "TERM","Field name" and
various other words you mentioned which you left completely unclear).
> 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.
Exactly. And e.g. the RADIUS attribute Service-Type has values that are in
{ Login-User, Framed-User, Dialback-Login-User, Dialback-Framed-User,
Dialout-Framed-User, Outbound-User, Shell-User}.
I might have missed other possible values. Do you see, how the term value
is completely justified?
> I suspect that your computational domain is "strings".
No, it's rather "elements defined in the dictionary".
> 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.
Sorry, I'm lost in your wording and can't answer the question. :-(
> 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)?
Yes. It's a value. If it helps to clarify things, on the byte level, "PPP" is
represented by a 32-bit-integer with value 0x00000001 (in network byte order).
> 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!
Well, if you want to call attributes "fields", feel free to do so, but don't
be surprised if nobody understands you.
> 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?
Right. Attributes have _values_, not other attributes. Feel free to call
them constants, if that simplifies your life, but again: Don't be surprised
if other RADIUS users have problems understanding what you're saying if you
do.
> I chose to believe that it is a constant, because it is lexically
> distinct from what I expect a variable name to look like.
Anyway, variables don't really exist in RADIUS. If you find them, it's
a proprietary extension of a specific RADIUS server. FreeRADIUS is using
something like '%{something}' for variables.
But again, how you would expect something to look like is totally irrelevant
in the case of FreeRADIUS. What a certain string is, is defined in the RFC (and
in the dictionary files), and there is no way to tell anything without actually
looking it up. However, if you look at stuff like "A = B", A is _always_ going
to be an attribute (field, if you insist) and B is _always_ going to be a value
(constant, if you want to call it like that). However, simply looking at an "A",
there is _no_way_whatsoever_ to decide whether it's an attribute or a value,
except for looking it up.
> So what distinguishes literal constants from field names in your
> language? Not the "-" signs, you have said!
Nothing. You have to look up the definition in the RFC (or in the dictionary).
I totally agree that this is confusing, initially.
> > 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.
It is using the language defined by the RFC. If you look at gcc documentation,
do you claim that it fails, as documentation for users, because it doesn't
explain the C syntax but simply refers people willing to learn C to other
sources of documentation?
Why would you expect the implementation of the RADIUS protocol, to re-explain
RADIUS terminology instead of refering people to the RFC?
> 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.
Continuing the sample from above:
"You are supplying the implementation of a C compiler, therefore we need to
know how to deal with the compiler, not how to deal with C".
Sorry, this is plain ridiculuous.
> If *I* say that your documentation is
> incomprehensible in parts, it *is*.
It certainly is, I can agree with that. However, I can't agree with the
reasoning that it's incomprehensible because it's written in greek while
it should be written in latin and because if comes without a complete
dictionary of the language it's written in and only tells you were to
find said dictionary.
> 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.
The problem is, if they fix it, the way _you_ suggest, it will seem backwards
to everybody having had a look at the RFC.
> 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?
Are you seriously suggesting that the documentation should use non-standard
terminology (i.e. not the terminology introduced in the rfc)?
> 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!
;-)
> > 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 "<-".
You really are suggesting that documentation should write "->", where the
RFC writes. "<-". :-(
> 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,
It _is_ 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?
Variables don't exist in the RADIUS language.
> 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?
Exactly. If a specific A-B-C appears on the left side, it's an attribute
(or field name or name of a variable or whatever you're going to name it in the
next paragraph), and it can never appear on the right side. If it's appearing
on the right side, ist a "value" (or constant) and never can appear on the left
side. All this is taken from the RFC where it is explained in much more detail.
> I am not confused, thank you, you are. And the reason is probably that
> you have been working with radius for a decade.
Me too. I "discovered" FreeRADIUS a couple of months ago and found everything
quite clear (though it's offering lots more features than any RADIUS server
I saw earlier, which also adds lots of complications). If it had used of
non-standard terminology however, I'd thrown it out as fast as I could.
> > > 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.
RADIUS allows values (constants) only, everything else is a proprietary
extension
of FreeRADIUS.
> 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?
Yes, thanks. However, I don't think, any compounds are allowed, so TERM is
easily leading to people expecting more than is available, i.e. it's not a good
term to use, IMHO. Really, constant would be much more appropriate in general,
with a note that FreeRADIUS might be allowing variables here and there.
> I interpreted PPP as a constant.
Exact - though the reason for it being a constant has nothing to do with not
using "-" or using capital letters only. "Framed-User" is a constand just as
good as "PPP" (and both names come fromt he RFC).
> 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!
Now I understand how you reached that misunderstanding. Alan was saying, you
should be thinking of the left hand side as attribute name (or if you prefer:
as name of a variable), while you should think of the right hand side, i.e.
the "values" (according to RFC terminology) as the value of the variable.
Fog cleared at least as far as this point is concerned?
> 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!
I think you rather should try to convince the authors of the RFC, to
fix their wording, if it really needs fixing - I certainly expect products
implementing an RFC to use that RFC's terminology in their documentation...
Regards,
Stefan
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
