> >Until today,
> >The programmer, working on the tools made some changes to his code, to
> >reflected the latest changes in de RFC. And it stopped working!
> >What is wrong?
> >Somewhere, between draft-06 and the current RFC the
> >definitions of the fields, mostly HOSTNAME and
> >TAG are changed!
> >On paper, it's correct. But functionally there is a bug!
> I'd have to agree with you. On the other hand, the official response
> you're going to get is that the Syslog working group's job is only to
> document the current use of Syslog and to provide mechanisms
> to secure it. Making the log messages useful is outside the scope of the
WG.
Hai all,
Even when the "job of the WG" is to describe the current working ONLY; we
have failed in my opinion.
First, all documentation of syslog describes the TAG as program *and* PID
(at least). See e.g. the manual pages of syslog (3); the API speaks of
"ident" (which I call "location") and mentions it's (by default) both!
Ofcourse, an API isn't the same as a protocol. However, it's hard to design
a protocol years after the API is in use, split a logically string into
two field and hope it will work forever!
Second, when oor job is to describe it, it's also our duty to *describe* it
GOOD. Not to change the current practice, not to break existing code, nor
to make improvements. That's what I'm complaining about.
I'm complaining about the fact that (in my view) the quality of the
description isn't right!!
The description in an "old" draft was GOOD. I did made some suggestions in
the past to improve it even more. Some where accepted, some not. The
resulting
draft was described the current behaviour even better; and was GOOD to read.
And more important: when implementing new tools according to the draft (we
did), it was:
a) possible (even easy) to implement, as it was clear what to do
b) working the same way existing tools did. The interworked!
After the change to the lasted (the official) RFC, the *description* wasn't
GOOD anymore: we did reimplement/rework the code, to be as close to
the spec as possible. That is where the problems did arise; sure we can
solve them. We already did.
But, implementing syslog "GOOD"; becomes harder; bug's come easily. And the
code becomes less clear (for people that only have access to both the RFC
and the code).
The only reason I'm arguing this "hard" is: this RFC is basic; it's a
base document for other rfc's; like syslog-sign and -reliable.
When the base is "wrong" (read: hard to get it right), it become very hard
to get the other "right". Which means also, it's hard to get the
syslog-sec's
accepted!
And that is our mission, isn't is. Not to produce paper, but to invest in
syslog,
and to make "the syslog family" secure, useful and a defacto standard.
--ALbert
sent mail to [EMAIL PROTECTED], to address me personal.
sent mail to [EMAIL PROTECTED], to address me for businesses
