Andrew, Just some additional spice to my message to Andrew. Be warned: I am touching payload which some consider outside the scope of this WG ;)
> Maybe a mention should be made in the spec that systems > intended for the > global market SHOULD include a US ASCII English sending option. > Firewalls, routers, switches etc that generate system logs for machine > parsing, SHOULD speak English. > > Other devices and software that send messages to local > operators or net > admins, could speak the local tongue. > > If a product is to be made available outside of the country, then > allowances should be made to speak English. As I wrote - provide the standard and let the market work... > > Parsers have a hard enough time making sense of our current mixture of > syslog message formats, let's try to be sensible out there :) Let me pick this up from a different angle: in my point of view, parsing is made hard not by different languages but by the lack of a syslog payload (read: MSG/CONTENT) standard. If there would be a standard like: TYPE=DataSend LOCALPORT=1933 REMOTEPORT=80 HOST=www.example.com PROTO=TCP ... MSG="URL zugeriffen" TYPE=AccessDenied LOCALPORT=14556 REMOTEPORT=25 HOST=www.example.com PROTO=TCP ... MSG="Zugriff Verweigert" Don't you think you could parse it without knowing German? In my point of view, the missing payload format is the #1 issue when parsing logs. If you had defined fields and a field for the human-redable message (in local script;)) you would not have any issue at all. OK, this is not an immediate task. But as long as we do not provide any payload standard, it is not started and thus takes longer to complete... ;) Rainer
