WG,
we have been discussing which of these fields to include as required in
the header. This discussion so far has not looked at existing technology
and standards. I am not talking about backwards-compatibility at the
protocol level, but rather about the "real" log emitors, the
applications.
A very common use for syslog is event notification under Unix, Linux and
similar systems. There is a system call (API) to do that. This system
call is not necessarily be bound to network syslog format. Depending on
syslogd configuration, only local logging might be involved. As such,
this part of the "syslog process" is completely beyond IETF-control.
However, the way the APIs are standardized there has some effect on what
we can do on the wire. In POSIX, only a single string is specified to be
used for identifying a message (besides, of course, the message itself).
The same is true for glibc on Linux and other platforms. The concept of
a MSGID is unknown to both. glibc extends the caller-provided string by
the process ID and a colon and blank is appended to it. E.g. "myname"
will become "myname[processid]: ". This is put into the field we
currently know as TAG.
The reason I am telling this is that we must find a way that a new,
-protocol compliant syslogd can obtain the information it needs to put
into the fields. I think we can not wait until the POSIX standard or
glibc is updated (if ever). Even if they add support, probably the vast
amount of software would still use the previous API and thus not provide
any more information.
For APP-NAME and PROCID, a new syslogd can extract the information from
what is logged by the applications. It can subparse the TAG value
(received via local interprocess communication, some kind of API) and
extract them (APP-NAME is everything before the first '[', PROCID the
value between '[' and ']'). MSGID must be set to unknown ('-'), but this
is not problematic in such cases. Of course, newer software can call
into an enhanced syslog library which fills all fields natively. But I
think we must support the currently existing API.
If we go for just MSGID, I have no way of mapping with the existing API
other than to put the current TAG value into it. That would not be
benefitial.
So my reason for insisting on all three header fields is that we must
support existing non-IETF standards and APIs while still enabling new
devices and programs to support advanced format.
Rainer
_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog
