Hi,
> Well, as everyone could have guessed, they talk aboout "fields".
>
> A summary of the RADIUS data format is shown below. The fields
> are transmitted from left to right.
>
>
> They then switch to calling them "attributes", for no good reason.
Nope. They call one particular field the "attributes field", because that's
the field in the whole packet transmitted over the net which contains the
attributes needed for authentication.
> The second use of the word is:
>
> Once the client has obtained such information, it may choose to
> authenticate using RADIUS. To do so, the client creates an "Access-
> Request" containing such Attributes as the user's name, the user's
> password, ...
>
> So again, use without definition. This is very poorly written.
Nobody ever claimed RFC's are well written. However they still define the
terminology in the area where they apply...
> Attributes
>
> The Attribute field is variable in length, and contains a list
> of zero or more Attributes.
Exactly what I have been saying above: The "attribute field" of the whole packet
contains individuel attributes.
> What they MEAN is that there is a contiguous (trailing) area of a packet
> called the AttributeS (note the S) "field".
Sorry, I'm no native speaker, so I can't appreciate that linguistic difference.
To me, it's exactly identical when translated to my native language.
> And unsurprisingly it
> contains a contiguous sequence of areas each of which they describe as
> "an Attribute". The number of those is not fixed from packet to packet,
> and I presume there are as many in each packet as will fit in the length
> stated via the contents of a certain fixed earlier field of the packet.
Exactly.
> Doesn't it make a difference when somebody writes properly?
I don't know. It's all still english to me.
> A 1 one-byte type field. So there are only certain fixed field-names?
Exactly. The attribute names from the dictionary.
> Up to 256 of them. Only 63 are defined.
Careful, there's a mechanism for extending that domain, there are in fact
63 standard attributes and several hundred vendor attributes defined by an
extension mechanism we don't need to go into. The point is, the attribute
names are not restricted to 63, not even to 256.
> There's a 1-byte length
> follwing the type, so the field can be a string of up to 256 chars
> (well, 253, I suppose). Well, it appears the values in the "Attributes"
> can come from a union type of strings (yes, 253), ip addresses, 32 bit
> ints, and time.
essentially, yes.
> So indeed, I was right, you do have "field names". They are precisely
> the ones I thought they were:
>
> 1 User-Name
> 2 User-Password
> 3 CHAP-Password
> 4 NAS-IP-Address
> 5 NAS-Port
> ...
Exactly. Only, they are called attribute types.
>
> So I guess you can have variables that simply have any name except
> those, if you have variables. Do you?
No. Imagine the left hand side as always being one of those 63 reserved names.
> Gawd ... then there is an extremely boring listing of the packet layout
> of each of the kinds of field!
The point is, it also defines the values, that are permitted for that attribute,
take for examples section 5.6 which describes the "Service-Type". There it says:
Value
The Value field is four octets.
1 Login
2 Framed
3 Callback Login
4 Callback Framed
5 Outbound
6 Administrative
7 NAS Prompt
8 Authenticate Only
9 Callback NAS Prompt
10 Call Check
11 Callback Administrative
And it's giving a precise description, what the semantic of each value is
supposed
to be.
> Let me skip.
>
> Uhhh .. I think it stps around page 58.
>
>
> Now I still don't know anything about your use of the words value
Because you skipped precisely that ...
> and variable and so on,
? I've been talking about attributes (attribute names, "field" names) and
values,
exclusively, haven't I?
> or what you have in your little language, but I can
> tell you taht what I saw in the RFC was entirely standard and had
> NOTHING WHATSOEVER TO DO with your language, except for he ome point:
> that you seem to have preserved the field names ("attribute type" names)
> used in the RFC in your language.
And the value names. I admit that the syntax "attribute type = value name" to
describe that an attribute of the given type with the given value should either
be checked for existance in the query or should be added to the response" is
neither coming from the RFC nor very intuitive, the only thing I can say in it's
defence is that every RADIUS server is doing it this way. I didn't look at what
FreeRADIUS documentation says in that respect (as when I had first contact with
FreeRADIUS, all this was already well-known to me), but I believe you when you
say there's room for improvement there.
> Now I still don't know what your terminology is or where it cmes from,
> and I am not going to read the other 31 rfcs to find out. You can
> describe your configuration language.
>
> Why should *I* do this work for you?
Why should *I* do this work for you? I'm just as much of a RADIUS user as you
are, and you are the first one to actually criticize the documentation in that
respect, AFAIK. It's good practice in open source projects to actually
contribute improvements if you find something which needs improvement and which
you can improve. It's unlikely that somebody else is able to read your mind and
fix it in the way you like ...
> Do you want me to look for uses of the word "value" in the rfc?
As I said, it's defining the exact values for each standard attribute in the
section you skipped. Having a look at one or two samples should be widely
sufficient to get the idea.
> >
> > > 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
>
> If you mean the same rfc I just read, it was about 80 pages, and had
> nothing in particular to do with whatever you have in yoru config
> language.
Well, it's defining the strings permitted both on the left and on the right
hand side
of the "=" symbol. If you think this "has nothing to do with the config
language",
then I must admit to be lost and not understand at all what you're talking
about.
> If you mean another one, you can jump -
No, that's the right one (well, essentially. rfc2865 is it's current version...)
> Using the same terminiology as everyone else is the simple goal. The
> rfc I read had it right. Now you get to get it right too!
Then, I'm lost as to what your point really is.
> > 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
>
>
> Which is? I've just read it
>
> Remote Authentication Dial In User Service (RADIUS)
(snipp)
> and it contains nothing at all about your strange usages.
It contains all about permissible attributes and their permissible values
(well, almost;
it only generally describes the mechanism for vendor-specific attributes and
their values,
which needs to be looked up in vendor specific locations, but they really are
nothing
which is lexically much different, especially when not looking at the packet
level).
> > intuition". Sorry, but I feel like you're trying to use PASCAL syntax and
> > complaining
> > about a C compiler rejecting stuff as invalid.
>
> Then you would be wrong. I know many more languages, indeed _classes_
> of languages, than you, and I probably wrote more than you know anyway.
Of course. My field of work is chipcards, cryptography and maths, i.e. nothing
where
you usually need to define a new language.
> > RADIUS (i.e. the RFC) defines dozens, probably even hundreds of values
> > which do
>
> No it doesn't. I just read it and it defines 63. They are INDEED field
> names. So where are you coming from?
It defines 63 attribute types. And for all of them, it defines the permissible
values,
which typically are either IP-Adresses, or strings or a couple of predefined
values.
If you look at all the attributes taking predefined values (in those pages
which you
skipped) and count the values, you will find that there are quite a lot of them.
>
> > look like this. PPP, Framed-User, Session-Timeout, etc., all those are so
> > called
>
> PPP is not defined.
It is. See section 5.7 where the permissible values for the attribute
"Framed-Protocol" are listed.
> It is an ordinary string. There is nothing special
> about it. I presume your misapprehension comes from this section of the
> rfc:
>
> The NAS MAY include the Attributes Service-Type = Framed-User and
> Framed-Protocol = PPP as a hint to the RADIUS server that PPP service
> is expected.
>
> But you can see from that that they are ordinary strings. They have no
> reserved meaning.
100% wrong.
> They are not "field names".
Exactly, they are _not_ attributes, they are _values_.
> Can you please get it through your heads that there is nothing much to do
> with radius in your config language?
Can you please get it through your head that your prejudices are partially
wrong?
> It is a syntax, nothing more.
> Languages are just that! They have an intended semantics and that hels
> us to understand them, but in themselves they are just collections of
> syntax.
>
> As such, when you write
>
> A == B
>
> You must be able to tell me what the syntactic class of A an B is
> restricted to be. I think it is:
>
>
> Field-Name '==' Expression
Entirely wrong. It is:
Attribute (as listed in the RFC) '==' Value
And
Value ::= Literal-Constant (as listed in the RFC)
| <Ip-Adress>
| String (with length limit).
[ FreeRADIUS also does some magic with variables, but that's not typical for
RADIUS servers (and I know strictly nothing about it), so please let's ignore
this.]
> But you won't say and haven't said.
Then that's a point where I agree the documentation could be improved by
somebody.
> When you make it clear what
> the syntactic rules are, then I can begin to attach a semantics to your
> constructs.
>
> Now it seems that I was right and "PPP" is a constant. However, the
> person who wrote in and suggested
>
> xyz Foo == FOO
> Bar = FOO
>
> as a way of filling field Bar with the value of field Foo was
> apparently mistaken.
That was supposing _you_ would substitue some value for FOO, such that if the
attribute Foo has the value represented by FOO, the attribute Bar is filled with
the value represented by FOO, as well. Having a variable content in any field
besides Username, Password and any attributes identifying the client talking to
the server is rather unusual for RADIUS and passing that value on to another
attribute is something which many RADIUS implementations will just refuse.
> He has been mislead by your mistaken texts, which
(BTW, not _my_ texts, so far I didn't contribute a single line to FreeRADIUS or
its documentation)
> do NOT make these things clear in the way they ought to.
Now, he was mislead by your unusual requirement to pass a value from one
attribute
into another one. As I said, not something RADIUS normally supports. The typical
way to do it really is
xyz Foo == value1
Bar = value2
xyz Foo == value2
Bar = value2
and be done with it. Of course, that's something totally inappropriate for your
original sample with an ever changing string as value.
> And the rfc ays nothing about your config language. Not the one I have
> read, anyway.
Yes, that's what I also realized when looking at it again to answer your
questions.
All I can say is that it's a config language shared by all RADIUS servers I've
ever
seen (except for FreeRADIUS specific extensions, which I don't know well-enough
yet
to say anything about them) and I don't remember ever having seen a concise
definition
of it. Somehow, everybody appears to assume that it's self-explaining.
> > values. And e.g. User-Name, Framed-IP-Adress, NAS-Port are so called
> > attributes.
>
> No, they are NOT. Those are the NAMES of so-called "attribute TYPES".
Yes, that's the more exact wording. However, everybody is using "attribute" as
name for the 'name of one of those so-called "attribute types"' because the
latter
is a bit longish.
> These are predefined and fixed numbers that appear in the packets. You
> can call them anything you like in your little language, and use any
> syntax you like.
Sure. But not inventing a new syntax simplifies things a lot ...
> But thankfully you have used the same names in your
> language as appear in the rfc for the packet contents, but DO NOT
> CONFUSE THE TWO. Youhave complete freedm in designing your language. It
> only behoves you to explain it.
>
> For example, there is nothing stopping you allowing
>
> Request: x <= User-Password, User-Name == "Fred"
> Reply: x => CHAP-Password
>
> as a syntax. Or, more like what you had:
>
> Fred User-Password == x
> CHAP-Password := x
Only that it won't work because CHAP-Password (if you look up it's description
in section 5.something of the RFC) is not a permissible reply attribute. ;-)
You really do have to have the RFC at hand to be able to make up a reasonable
configuration or even a reasonable example.
But let's ignore that for now.
> And this is a perfectly comprehensible and likely syntax and semantics.
> We need to be TOLD that you in fact interpret it as:
>
> Request: User-Password == "x", User-Name == "Fred"
> Reply: "x" => CHAP-Password
>
> Because we CANNOT TELL by looking at your text and examples.
Err, wait. You mean to suggest, the above should set the CHAP-Password (or
something more reasonable) to the value you passed in as User-Password?
No, that's not the way it works, it's _much_ more stupid. there are no
variables. If the User-Password is "x" (literally), then it would set
CHAP-Password to "x" (literally). If you pass anything else for User-Password,
then the rule gives you a reject and does not set CHAP-Password to anything.
> > 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.
>
> No, thank you , but I am QUITE capable of figuring out whatever it is
> you mean, as soon as you take the trouble to SAY.
>
> If you don't say, I and everyone else have to GUESS.
>
> When we guess, and we put our guesses to you, we do not expect to be
> told "go read the rfc", but "oh - yes, I see, we didn't explain how to
> use that - we'll fix".
(Again, wrong adress. I'm in the same boat you're in with the difference of
having
been exposed to RADIUS (_not_ FreeRADIUS though) for a couple of years already.
> I have no idea what you are talking about. You have a view of something
> taht i have not read, and I have just read 80 pages simply to be able
> to reply to your mail.
Perhaps it's a small consolation that I also had to look at it again to answer
you're mail, but since I did write my first mail, I felt somewhat obliged to
clarify a couple of points, even if it means more reading/writing than I
initially
wanted to invest. ;-)
> > key point to the people who invented the RADIUS protocol and wrote the RFC.
>
> There is NOTHING to do with radius in the technicalities of your
> language! Please get it through your head! We are talking about
> whetehr you write your variabes on the left or on the right,
THERE ARE NO VARIABLES!!!!
> or whether you use capitals to designate named cojnstants, etc.
Constant names (just as attribute names (aka names of attribute types)) come
from the RFC...
> Those are purely lexical and syntactical considerations, with a
> smidgeon of programming language semantics thrown in. Nothing to do
> with radius.
You're trying to find a much more complex language in there than there
actually is, complaining that things are looking the same when you wrongly
believe they are widely different and complaining that there is no visible
difference.... :-(
> > > 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.
>
> Forget radius! Your language has nothing to do with it at that level!
>
> And the radius rfc that I just read uses words fairly normally! It has
> been your use of them in connection with programming language that has
> been odd so far!
There's no programming language involved. Only sets of attributes which need
description (and Attribute-Type=Attribute-Value seems perfectly reasonable
to me).
> I don't know why or how you have convinced yourself
> that your usage is normal, but it is not, for all the sense I can make
> of it.
That's because you're trying to make much more of it than there is...
> I am not! I am using the same language as the rest of the computing
> world is using, and the rest of the world is using computers ... if you
> have got something upside down somewhere, and I don't know, theny
> please fix it! The radius rfc I read is perfectly OK (apart from the
> usual faults of a rfc) and the strange language appears to originate
> with YOU.
Actually, not with ME, but with the author of FreeRADIUS documentation. In fact,
probably not even there but with the author of the documentation for the very
first
RADIUS implementation (i.e. the authors of the RFC), as the configuration
language
is pretty much standard.
> Do you want me to list the use of the word "value" in the rfc for you?
> I can assure you that no special meaning is assigned to it! It is used
> in the ordinary standard way, as an element of a semantic domain. The
> values of "Attributes" in a packet come from a well-defined domain.
And those are the values that are used in the configuration file.
> Now, when you come to your LANGUAGE, you will have TERMS and an
> INTERPRETATION of those terms. Your language defines
> declarative programs which are INTERPRETED as instructions on how to
> respond to certain types of incoming packets in a radius protcol.
> That's all - there's no mystery.
Exactly. If the incoming packet contains specific attributes having specific
values, do reply with another set of attributes having specific values.
E.g. if "user 'stefan' is logging in with password 'test', accept the query and
add 'Framed-Protocol=PPP' to the answer", would be written as
stefan User-Password=="test"
Framed-Protocol=PPP
What's so unclear?
> Of interest in your language is merely the linguistic mechanisms it uses
> to define the interpretation. It doesn't particularly matter that the
> intended interpretation is as a responder to radius calls. Above that
> there are variables, constants, scopes, all that kind of thing. I.e.
> generic computational lingusitics. It is THERE that your usage does not
> seem to be in accord with the rest of the world - radius does not come
> into it.
You're looking for something which simply does not exist!
> > i.e. the RFC? It's going through dozens of pages and samples to define the
> > meaning
> > of "attribute" and "value".
>
> No, it doesn't.
It does. The pages you conveniently skipped.
It's all about defining standard attributes and their possible values...
> So please do not confuse the issue. That you have certain special
> names for special constant values (in special contexts?) is an
> unimportant feature of your language - merely a convenience to adapt it
> for the chosen domain. I would guess that your interpreter would be
> happy if you wrote "1" instead of "Login".
No it isn't. You have to use the constant names from the RFC - in _all_ RADIUS
implementations I ever encountered. That's just to avoid configuration files
looking like
test 6==1 5==2
8=7
(I.e. if user test queries access with attribute type 6 having value 1 and
attribute
type 5 having value 2 accept and reply with attribute type 8 being set to
value 7.
Looking up the attribute types and values will probably show that it's
complete nonsense
even wqith that interpretation, but you probably see why nobody would want
similar
configuration files)
> And note that the names they use are not precisely the ones you used.
Probably spelling errors in the dictionary I (ab)used to write my initial mail.
> That leads me to suppose that you don't have context sensitivity in the
> interpretaton of constants in yoru language. You've suffixed "-User"
> to the names in order to define a context as part of the name,
> converting them into globals instead.
No. No special meaning, just errors on my part.
> 1) Your language contains certain reserved symbols with special
> interpretations in certain contexts
> 2) In the appropriate context and on the RHS of an == or = or .. sign,
> the symbol "Login-User" stands for a CONSTANT of a certaib fixed
> VALUE.
> 3) The appropriate context is at least when the token (reserved word -
> a field name) Service-Type appears on the left of that == or = or ..
> sign,
>
> I don't know if there are any more contexts in which it may appear.
Probably not. RADIUS is pretty good at having totally different names for
all the possible values of different attributes.
> I don't know if it retains its special interpretation within a compound
> expression.
There is no such thing as a compound expression (at least not generally, I
don't know about possible FreeRADIUS specific extensions).
> Those are things I require you to tell me, in order to
> describe your language adequately.
>
> Note that I have
>
> A) defined the syntactic conditions for the appearance of the symbol to
> be valid
> B) defined the semantic interpretation of that symbol, when it appears
> validly.
>
> That's all.
I start to get your point...
>
>
> > > I suspect that your computational domain is "strings".
> >
> > No, it's rather "elements defined in the dictionary".
>
> Well, it was strings up to 253 chars plus 32 bit ints plus a couple of
> minor things that I forget.
Well, typically you can't use the ints but need to use the name for a constant.
And I totally forgot about the strings as there are not many (frequently used)
attributes actually taking string values. Most of the time, it really is the
name of a constant, i.e. one of the elements defined in the dictionary.
I admit that I tend to overly simplify the whole thing...
> > > 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. :-(
>
> Why? The wording was normal. I asked you what the things on the right
> of = signs could be:
>
> 1) literal constants (whose value would be a string ..) or
> 2) variables (whose value would be a string ..) or
> 3) compounds of 1) and 2) in some more complicated term.
>
> Where is the difficulty? This is a normal way to define something
> constructively.
Ah, OK, got it. Probably my parser for english was choking a bit, yesterday
(also, I hadn't yet understood, what kind of mysteries you tried to put into
that configuration "language". ;-)
So the answer is that the right hand side consists of literal constants.
> > > 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).
>
> Well, the rfc does not say precisely what I think you think it says. It
> says:
>
> integer 32 bit value, most significant octet first.
>
> And you will note that the order of bits within an octet is not
> defined! So you would only be justifed in writing
>
> 0x0:0x0:0x0:0x1
>
> but we won't find a problem easily there!
OK, a clear definition of octet is missing... ;-)
> > > 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.
>
> It's a field in every sense that I understand it, and that everyone else
> understands it. There is an incoming record (a packet) and it has
> fields. The name of one of those fields is "Framed-Protocol". If yu
> want to call it an attribute instead, I don't mind at all. That is also
> a conventional use of the word, and the two mean the same. One is used
> in the database context and the other in the OO context... the overlap
> is substantial and in this case the sematics falls within the usual
> scope of both.
Aha, we do reach some understanding ... :-)
> > > 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.
>
> Nobody suggested they have anything else than values. What else could
> they have?
>
> > Feel free to call
> > them constants, if that simplifies your life,
>
> No, they are not constants. Attributes, I mean.
Agreed. I meant, feel free to say "constants" or "constant names" instead of
values.
> They have values which
> are values. There is nothing funny about that. Apparently PPP however
> is a predefined NAMED CONSTANT, which I did not know. I thought it was
> a constant, but the LITERAL constant "PPP", since there was no
> indication to the contrary and PPP is a common word. I didn't know its
> value was not the string "PPP", but the number 27 (or whatever it is).
And there really is no need to know it. If the documentation of my radius client
tells me, it's expection the attribute "Framed-Protocol" to have value "PPP" to
establish a PPP connection to a user, I just add "Framed-Protocol=PPP" to the
configuration and I'm done. No need to know if PPP is a named constant (with
value
1 or 27 or whatever) or a literal a string.
> > 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.
>
> There is no indication that they don't exist. Languages normally
> contain variables, or they are not useful.
It depends on your context. Of course a programming language without variables
would be a nightmare. A RADIUS server not supporting variables in its
configuration
file however is still fully functional.
> Everyone who has read the
> docs and who has written to me privately (not a great number,
> admittedly, but some) has said that they believed they do exist, and
> cited the examples given in the docs as evidence.
Again, that's a FreeRADIUS extension, which I know nothing about. I'm only
trying
to get the simple things straight that I understand.
> No, I haven't seen it. But I am willing to believe there is ANOTHER rfc
> that defines something like "a configuration language for radius".
AFAIK, there isn't. Somebody coming up with a good general description really
would fill a gap in current documentation. Every server I've seen essentially
relies on people looking at examples and using/modifying/extending them step
by step... :-(
Once you do have the basic understanding that "everybody" appears to take for
granted, I _suppose_ (no sorry, I won't start reading them now) the server
specific documentation for the specifics of the server does make perfect sense.
> > 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",
>
> OK, in your language, I might be willing to believe that the rhs is
> restricted to be always a constant term, but it isn't, because you
> allow at least also
>
> A = `%{0}`
>
> as I personally verified. So come clean! What IS allowed on the rhs?
Sorry, I've been talking about RADIUS configuration in general, _not_ about
the specifics of FreeRADIUS which you already know better than I do.
> Named constants? Literal constants? I bet the latter too.
In the case of attributes taking string values or IP adresses or arbitrary
integers,
yes. Not if only few values (for which named constants are provided) are
allowed.
> Variables?
> You say you don't have any, but the above looks like some kind of
> variable to me - fix your syntax a bit and it would be fine. Compound
> expressions? You already allow the ` ` operator. What else?
Again: FreeRADIUS specific extensions.
> > there is _no_way_whatsoever_ to decide whether it's an attribute or a value,
> > except for looking it up.
>
> You are saying that the lhs may be either a field name or a named
> constant (or a literal constant)?
Nooooo! I'm saying that you can't decide if a given identifier is an attribute
(field
name) or a value (constant name) by counting dashes or looking at upper and
lower
case letters or something. The only way to decide is to look it up.
> Mind telling me where the lexer and parser are?
No idea for FreeRADIUS. For my own primitive RADIUS server, it's a simple
routine
which first decides, if it's on the left hand side or on the right hand side.
If on the left hand side, it looks up if the character sequence it finds there
is
defined as an attribute (field name) in the dictionary file(s), if it isn't,
it's
an error. For the right hand side, it checks the "type" (domain) of the
attribute.
If it's an attribute taking a string as value, it checks the right hand side
looks
like "some value" (with the quotes) and takes the stuff between the quotes as
the
value of the attribute. If it's an IP-Adress, it takes an IP-adress, if it's an
integer it accepts either an integer (AFAIK, FreeRADIUS is more strict in this
request) or a named constant. For the named constant it looks into the
dictionary,
if it finds a definition of that constant, fine, if not, there is an error. It's
about 150 lines of pure C code (not counting the functions handling the
dictionary
files), but I'd rather not try to write something suitable for FLEX from it.
All those named constants and attribute names would drive me crazy.
> > It is using the language defined by the RFC.
>
> I don't see it! And no it isn't, as far as I can see. But maybe you are
> looking at a different rfc.
No, we are looking at the same one. It's defining all the named constants and
the attribute names (expect for vendor specific extensions) and there really
isn't much else to the configuration language, if you leave FreeRADIUS specific
extensions apart.
> > "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.
>
> No it isn't. That is precisely why gcc documents the things you
> need to particularly know in order to deal with gcc.
(snipp)
> We need to know that, and the gcc info pages tell us so.
Point conceeded.
> Now - people who use C are interested in writing in C. Their livlihood
> probably depends on it.
>
> OTOH, people who use freeradius probably have no interest at all in
> configuriing and playing with it. They want it because they have to
> install some kind of authentication mechanism for users on a net. They
> have the same level of interest in it as in a password file.
>
> If you tell them they have to read (32!) rfcs to understand how they
> can set up a config file thatthey can then go away and forget about, it
> isn't going to happen. ow - you HAVE a very nice config file. I liked
> it! I understood it. I got it to work. I figured out the unclear bits.
Lucky you. Believe me, most people just pay some expert to come and set it
up for them, and depending on the complexity of what they want, if those
experts may need a couple of hours or even days to do it. Sorry, it just
isn't very easy or obvious for non-trivial cases.
> But I expect you to see whatthe problem is when I explain it to you.
That's OK with me (especially since I'm in no position to fix those
problems anyway... ;-) ), but I had the impression you were making up
a couple of non-existing problems by expection way to much of a very
simple-minded language.
> Do you have variales or don't you? What lexical chape are the? What are
> the syntactic classes that can appear on the right of an ==.
I've given you the simple-minded answers I've come across so far. Granted,
FreeRADIUS is superior to what I've known so far, so there's more room
for unclearness and misunderstandings.
> No it won't. It will seem right, because (a) I don't know what you
> mean, not having seen anything in the RFC I have read that is backwards
> (OK, OK, so that's not a "because"), (b) correct is correct, and if the
> rfc gets things backwards, that is no reason for you to talk funny,
It would be, because the description of server and clients really should match.
If one describes it forward and the other one would get things backwards, that
would really make things fun.
> (c)
> the customers for your config language couldn't care less if the rfc
> talks funny - they want straight talk,
No, they want talk compatible with the talk they got from the vendor of their
radius client.
> (d) I don't believe the rfc gets
> it wrong either (all the evidence I have seen so far is that if anyone
> is getting some things backwards it is YOU lot, and nobody else, not the
> rfc, which looks bona fide to me).
Mee to. But FreeRADIUS documenttion doesn't seem to be getting things backwards
either, IMHO. It's just your over-complicated attempt at interpretation which
makes everything seem backwards, as far as I can tell.
> > > A-B-C = FOO
> > >
> > > FOO is neither a variable nor a constant,
> >
> > It _is_ a constant.
>
> OK. But it's taken you a long time to say so (now, don't froth over!).
> And it's a NAMED CONSTANT. The word is reserved. Its value is
> not apparent. It is not a LITERAL CONSTANT (i.e. one which stands for
> the value it says it is, as in PPP has value "PPP").
And since the value is "opaque" and since I'm not going to write that
FOO is a NAMED CONSTANT meaning the value which it means, what's wrong about
calling it FOO the "value" of attribute A-B-C? Nobody ever should need to
get closer to the "real value" than that name defined by the RFC. It actually
does help (in my experience), if users do not start thinking that it really is
only a name and they might as well fill in the "real value".
> Just say that the things on the rhs of an = are limited to certain
> terms. Among them are named constants and literal constants
Yes.
> and certain "perl expressions".
Again: FreeRADIUS extension.
> The named constants have value in the
> domain of "radius values". I.e. strings less than 253 or so chars, 32
> bit ints and so on.
I think, the named constants really always have values that are 32 bit integers,
but I don't care, every server, every client, even every reasonable network
sniffer
is presenting me the "name" as the "value" of the attribute. I'd even go so far
and say that the "named constant" is the value and the "value" is only the
internal
name used to designate the value in a space conserving way.
> There is no need to make up words. And theer is no need to perpetuate a
> usage ouside of the context in which it is appropriate. Your language
> has named constants and literal constants like every otehr language.
> Their values are radius values. You don't have to start calling
> constants "values"!
> > Variables don't exist in the RADIUS language.
>
> Well, they exist in yours (the perl stuff).
Yes, FreeRADIUS ext... (OK, I'm going to stop that comment.)
> But thanks for that very clear statement.
>
> (that makes the language very limiteD).
Which it just is, yes.
> PPP is a reserved word. Its computational semantics (i.e. its
> semantics in the domain of all possible interpretations of the language)
> is that of a NAMED CONSTANT. In all interpretations of the language it
> has an interpreted value that does not change during excution, or from
> interpretation to interpretation. It's like "pi".
>
> Its semantics in any particular implementation (and hence all
> implementations) is the value 27, for all I know.
Well, it's value is "PPP", i.e. the protocol to be used, the "name" 27 (or
whatever) as an alternative for the name "PPP" is only choosen because that's
easier to fit into a network packet and interpret by the often very limited
radius clients.
> I don't care.
>
> It was not clear to me that it was a NAMED CONSTANT and not a LITERAL
> CONSTANT (i.e. the string "PPP").
What difference? The important thing is that it tells the access server which
protocol to use by a convention common to both radius client and radius server.
> I understand what you mean, but as we can both appreciate, the
> paragraph that I quoted is completely messed up. The author's intention
> is doubtless good, but what he has written is completely unclear and
> even tends to say the opposite of what he probably intended to say.
Because you're apparently paying much more attention to syntax than the
average reader, I'd claim. I don't think anybody else would have parsed
Alan's statement the way you apparently did...
Regards,
Stefan
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
