"Also sprach [EMAIL PROTECTED]:"
> 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?
If those are in contradiction with the normal usage of the word in
question in the rest of the intellectual universe, no, most definitely
and absolutely not. You should resist and oppose the use of speech
that is at variance with normal understanding (or find out next time
that you receive a goverment letter that by "date of reception" they
mean the date THEY sent it, not the date you received it ...).
But is it the case?
I don't know it is, and I really don't plan on reading the rfc to find
out. I haven't been able to make much sense of what has been said in
the thread so far, as it seems wildly inconsistent. Oh, OK, I'll read
just a little ... mmmmmmmaaaammma. You have included 32 rfc's!!!!!
Are you kidding?
Hmmm ... 2058 might be it.
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.
Many Attributes may have multiple instances, in such a case the
I presume that is because attributes are what is called "variable type"
fields. That is, the kind is designated by a code at the start of the
field. However, it is undefined. The very first use of the word
"attribute" in the file is:
All transactions are comprised of variable length Attribute-
Length-Value 3-tuples. New attribute values can be added without
disturbing existing implementations of the protocol.
So there is right there a use of an undefined term. Fail.
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.
I particularly like this one (at end of 4.3):
Attributes
The Attribute field is variable in length, and contains a list
of zero or more Attributes.
!!! Yeah. Are they trying to make a pastiche comedy sketch takeoff of
themselves?
What they MEAN is that there is a contiguous (trailing) area of a packet
called the AttributeS (note the S) "field". 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.
Hic.
Doesn't it make a difference when somebody writes properly?
I still don't know the on-the-wire format of "an Attribute", though!
Aha ...
A summary of the Attribute format is shown below
About time! Page 17!
A 1 one-byte type field. So there are only certain fixed field-names?
Up to 256 of them. Only 63 are defined. 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. They don't say if the int is signed, or indeed
how its bits are ordered within a byte.
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
...
So I guess you can have variables that simply have any name except
those, if you have variables. Do you?
Gawd ... then there is an extremely boring listing of the packet layout
of each of the kinds of field!
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 and
variable and so on, 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.
That's all, and you didn't have to.
Anyway, I can say that their usages are fairly normal. The rfc is about
normal for an rfc - it's fairly badly written, but that is the norm for
such things.
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?
Do you want me to look for uses of the word "value" in the rfc?
>
> > 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. If you mean another one, you can jump - i don't feel like
reading anoother rfc. I read fast, but people normally pay me to do it.
> 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.
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!
> > 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
Which is? I've just read it
Remote Authentication Dial In User Service (RADIUS)
...
This document describes a protocol for carrying authentication,
authorization, and configuration information between a Network Access
Server which desires to authenticate its links and a shared
Authentication Server.
and it contains nothing at all about your strange usages. On the
contrary, it's normal, if a bit badly written and carrying with it
the usual bad practices of unpractised (rfc) technical writers.
> 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.
> > 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
No it doesn't. I just read it and it defines 63. They are INDEED field
names. So where are you coming from?
> look like this. PPP, Framed-User, Session-Timeout, etc., all those are so
> called
PPP is not defined. 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. They are not "field names". The field names
("attribute type" names) come from a set of 63, and it has been your
CHOICE to implement them using the same name in yoru top configuration
language.
Can you please get it through your heads that there is nothing much to do
with radius in your config language? 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
And
Expression ::= Literal-Constant
| '\`' Perl-Expression '\`'
| ...
etc. But you won't say and haven't said. 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. He has been mislead by your mistaken texts, which
do NOT make these things clear in the way they ought to. And your
examples encourage such interpretations, because they ARE capable of
being interepreted as supporting them.
And the rfc ays nothing about your config language. Not the one I have
read, anyway.
> 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".
Type
The Type field is one octet. Up-to-date values of the RADIUS Type
field are specified in the most recent "Assigned Numbers" RFC [3].
Values 192-223 are reserved for experimental use, values 224-240
are reserved for implementation-specific use, and values 241-255
are reserved and should not be used. This specification concerns
the following values:
A RADIUS server MAY ignore Attributes with an unknown Type.
A RADIUS client MAY ignore Attributes with an unknown Type.
1 User-Name
2 User-Password
3 CHAP-Password
...
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. 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
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.
I do not know why you should need to have this told you! You are grown
people! It is normal to write doumentation taht explains - ahhhhh.
Perhaps you only write to document! That may be it!
Now you know why documentation is never read.
Because it is meaningless. It does not explain, if not written to
explain, but merely to document.
I'd hope you were writing for an auidence,
> 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".
> Yes, all this is "ugly", but it also is _very_ flexible, which obviously was a
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.
> 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, or whether
you use capitals to designate named cojnstants, etc.
Those are purely lexical and syntactical considerations, with a
smidgeon of programming language semantics thrown in. Nothing to do
with radius.
> > 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! 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.
> > 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.
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.
> > > 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
No they are not - you are confusing semantic and syntactic domains!
Words are TERMS. The semantics of a word is a VALUE. Please stop this
confusion. The rfc has no such confusion! It quite clearly gives the
sematic domain of VALUEs and does not confuse the NAMES of the FIELDS
which contain those VALUES with them.
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.
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.
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.
> 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..
I would certainly tell them to stp referring to you as "their daughter",
if they wanted me to understand who you were. It is conventional that
male children are called "sons".
Now, I don't even know if in yoru language you are descriing things
wrongly. All I know is that it is not explained.
> > 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",
Their use of value is quite normal and uninteresting in the rfc I have
read.
Oh - you have some OTHER rfc! Are you going to tell me which it is?
You have some other 100 or so pages you want me to read?
No thanks.
> 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'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).
A "field name" is an ordinary computational term. So is "term". We are
using them all the time. We do not have any trouble understanding each
other, because we KNOW what they mean. We were taught them in basics
of computing langugaes, in year two of university, or whatever, or
earlier.
From The Free On-line Dictionary of Computing (07Oct99) [foldoc]:
field
<data, database> An area of a {database} {record}, or
{graphical user interface} {form}, into which a particular
item of data is entered.
...
term
n 1: a word or expression used for some particular thing;
Etc. (note that a "term" is a syntactic construct, a symbol, and
it stands for a semantic thing).
So I at least believe that we share the common basis necessary to
understand each other when we use THOSE words. Just as we do when we
use the word "variable" or "constant".
> > 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}.
FIne! But those are just names for integers.
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
(I presume they mean it's an integer, not "4 octets", since they
didn't define "4 octets" as a valid subtype of their value domain,
but they did say "32 bit integer" was a valid subtype).
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".
And note that the names they use are not precisely the ones you used.
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.
> I might have missed other possible values. Do you see, how the term value
> is completely justified?
No - it's got nothing to do with it. What you have mentioned are
NAMED GLOBAL CONSTANTS
Like "pi".
There is no need to invent a word for it. Pi also has a "value". So
does Login-User. It is 1. They are CONSTANTS.
Now, the proper thing to say is:
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. I
don't know if it retains its special interpretation within a compound
expression. 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 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.
> > 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. "Sums" consist of
0) parentheses around what I will describe in 1), 2), 3) below, or
1) Literal numeric constants ("1", "2", ... with integer values), or
2) variables (whose values are integers), or
3) combinations of 0), 1) and 2) using +, -, *, /
And there you are. Sums.
> > 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!
> > 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.
> > 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. 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).
> but again: Don't be surprised
> if other RADIUS users have problems understanding what you're saying if you
> do.
I'm not using any terms in any unusual way. Quite the opposite.
> > 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.
There is no indication that they don't exist. Languages normally
contain variables, or they are not useful. 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.
> But again, how you would expect something to look like is totally irrelevant
No it isn't. It's completely relevant. We expect computer languages to
respect norms. That makes the difference between a usable language and
one which never gets used because it is incomprehensible.
> in the case of FreeRADIUS. What a certain string is, is defined in the RFC
> (and
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".
Anyway, it would define minima for such a laguage to satisfy, and you
would be free to have variables in it if you wanted, or have whatever
else you liked as extensions, so long as you maintain compatibility
with what the spec says you must have.
> 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?
Named constants? Literal constants? I bet the latter too. 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?
> 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)? That's fine by me. You have certain
reserved words. Good luck to you! But it can't be anything else?
Anyway, this is what you need to SAY!
> > 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).
No, you have a list of reserved words. You have to state them. Let me
look at how you do your interpretation ...
Numerical values are defined in include/radius.h. Nicely done.
Aha .. it looks like the syntax is defined maybe in mainconfig.c.
But I really don't see the grammar defined anywhere.
Mind telling me where the lexer and parser are?
> I totally agree that this is confusing, initially.
There's nothing confusing about having some NAMED CONSTANTS. You just
have to say. And you have to SAY what can appear on the right of a ==
sign in your configuration language.
There's nothing confusing about it! But leaving people to guess makes
them confused. Telling them gives them no opportunity to be confused.
> > > 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.
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. There are 32 to choose fom in yoru doc
directory.
> If you look at gcc documentation,
> do you claim that it fails, as documentation for users, because it doesn't
It works just fine, thanks, for what it is intended for. It isn't a
tutorial in C. But it gives more than enough data to learn from.
Well as it happens, I learned C++ from no other place but the g++ info
files (the C++ extensions sections). I have never read a book or any
other text on C++. C I already knew when I picked up C++, but I learned
C by buying a copy of K&R and writing a postscript driver with it,
about twenty years ago. Fortran I learned by reading the 80 column
cards I was feeding into an ibm 370 for a night job. Prolog I learned
by writing a decompiler in it. Miranda, ML, Hope, Ponder ... I am not
slow or deficient at picking up computing languages, and as I said, I
have very probably _written_ more than you have learned.
> explain the C syntax but simply refers people willing to learn C to other
> sources of documentation?
YOu don't seem to understand that you have YOUR own language. If you
don't tell people how to write in it, nobody will. Heck, people
complain at ME for not giving enough examples or tutorials.
> Why would you expect the implementation of the RADIUS protocol, to re-explain
> RADIUS terminology instead of refering people to the RFC?
I don't. I expect it to be completely irrelevant to a computing
language, and from what I have seen, it is. I don't know why you keep
making reference to radius! Your languages programs have an
interpretation as a radius server implentation, but the question of
their syntaxes, scopes, use of variables (by reference, value? etc.)
are purely computational and have nothing to do with the intended
action semantics interpretation.
Those are what you get the short straw on explaining sensibly.
Look, one of my languages declares variables like this:
aaaaaaa\x bbbbb ccccc
in which aaaaa is some term of the language, and bbbbbb is another. x
is declared for use in bbbbb, and anything to the right, like ccccc. If
you wanted to limit the scope you would use parens:
{ aaaaaaa\x bbbbb } ccccc
and then x would not be visible in ccccc.
It is THAT kind of thing that you get to explain, and have not.
> > 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.
No it isn't. That is precisely why gcc documents the things you
need to particularly know in order to deal with gcc.
For example, in gcc, you can do initializations that are rather cute and
complicated by saying something like
int x[] = { [0 ... 9] 1, [10 ... 14] 2, };
which would define x to be an array of 15 integers, the first 10 of
which have value 1, the last 5 of which have value 2.
We need to know that, and the gcc info pages tell us so.
Similarly, in gcc you can form expressions out of statements (in plain
C, you can make statements out of expressions, but not v.v). They have
to tell us how. This change changes the complexity of the language
immensely - beyond belief.
They get to document it.
As it happens, they can count on the fact that C is (a) simple and (b)
well known and (c) bog-standard in terms of imperative languages not to
have to tell us ALL about C But they have to tell us some things and
what they have to say, they have to say clearly, without jargon. By and
large they do so. I have always enjoyed reading the gcc info pages.
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.
But it took me some time - maybe 5 hours straight. OK - I was
handicapped becuase I was using a proxy radius client on a distant
machine with a web interface consisting of a python script that I did not
have access to. So I had to do a lot of guessing and fast. My interest
is zero in the server - I just want the client to authenticate OK
through the proxy. Even liking your config, and having the advantage of
a vast background in computing,your prose left me nonplussed. What you
wrote did not make sense, was unclear, and ambiguous. OK - par for the
course, You're not writers (for humans!), and I am. That's OK.
But I expect you to see whatthe problem is when I explain it to you.
You haven't defined the COMPUTATIONAL LANGUAGE you are using. Much of
your config file, all that expr, exec stuff, is deep dibdoo in terms
of how the explanations go. And even in the good explanations, there
are plainly unintended unambiguities and misdirections. I tl you about
some.
It oesn't take much to fix that! Just SAY.
> > 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.
You are making an excuse.
Making that excuse involves you in the pretense that your document is
the way it is BECAUSE it deals with a configuration language for
radius.
While it is the case that you need to relate the intended semantic
interpretation of your language to the semantics of a radius
server, it is NOT the case that you get to leave out or make
incomprehensible the purely COMPUTATIONAL aspects of your 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 ==.
Those are YOUR business, and nobody elses.
> > 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.
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, (c)
the customers for your config language couldn't care less if the rfc
talks funny - they want straight talk, (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).
In short, I think you are suffering from "lack-of-arms-length-itus".
Documentation should be written by someone who does NOT understand
what they are writing about. How else can they expect to take the point
of view of a reader?
Pretend you know nothing, and rewrite. DO NOT asume that anyone has
read the rfc, or knows what end of a variable is a constant or a value!
You got the docs mostly right! You just have to clean up some little
things that are confusing people.
> > 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)?
Yes. Of course! (and I most certainly dispute your parenthesised
contention - when did YOU stop beating your wife?).
> > 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. "<-". :-(
I am suggesting that it not use the symbol if it may cause confusion,
and that it say "causes" where the world means "causes" (to follow the
quantum gravity supersymmetry analogy), where the rfc would have you
write "is caused by". That way if there is any confusion caused by the
rfc's misuse (and I have seen n evidence of such), it remain limited to
the interface between you and the rfc, which thankfully we and the rest
of the world will not have to deal with.
You interface with the rfc, not us.
You interface with us.
> > 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.
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").
Just say that the things on the rhs of an = are limited to certain
terms. Among them are named constants and literal constants and
certain "perl expressions". 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.
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"!
> > 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.
Well, they exist in yours (the perl stuff). But thanks for that very
clear statement.
(that makes the language very limiteD).
> > 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.
OK. Some rfc I have never seen or heard of and have no interest in.
> > 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.
OK.
>
> > > > 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.
OK. Then freeradius needs to say.
> > 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
Well, OK. They need to say. I see some perl expressions in use as
terms on the rhs of = signs.
> 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.
OK.
> > 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).
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. 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").
> > 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.
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.
And (this is a criticism) I think that the lack of clarity results from
the author's lack of clarity in his own mind about how computational
languages are put together and how they work, plus his closeness to the
domain of application of this language.
> Fog cleared at least as far as this point is concerned?
Sure - there is no difficulty. If you say clearly what is allowed on
the rhs of an = sign, I have no problem with that. Named and literal
constants, plus some perl expresisions, I believe.
> > 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...
I don't. The rfc is the business of the author of the tool. What the
author writes is something that interfaces with people.
But I have seen nothing yet of an rfc that says anything unusual. ANd i
read one of 80 pages!
> Regards,
> Stefan
Thanks.
Peter
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
