While I agree that some sort of internationalization would be good, we lose the most important part of logging and that is a certain amount of expected output. Will German devices only start producing logs in German? Japanese devices in only Japanese?
Whatever we propose will need to be able to be useable to the majority but extensible enough such that those with non-English character sets can still gain more than what is currently available. Do we require these types of devices to be able to produce two types of logging output? We need something in between the two solutions. Richard -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rainer Gerhards Sent: Thursday, July 17, 2003 4:03 AM To: [EMAIL PROTECTED] Subject: Re: Syslog Internationalization /UDP Albert, >> I think that the internationlization is yet another last nail in the >> coffin of UDP syslog. > >> Its just Really Time To Move On. > >> [...] TCP syslog is workable, practical and effective. >> There is just no more room [..] UDP syslog > >I don't agree! > >UDP syslog is fine in a lot of cases. > >The question is where internationlization is always a good case. I >don't thinks so Yes, it is needed for "user applications, no we don't >need it in technical complex systems! I disagree with it. My real-world experience shows me that many administrators acutally prefer to have system messages in their native language. Some even tend to use local characters in system objects they create (where permitted, e.g. Windows computer names). I don't intend to argue if the later is a very smart way of doing things, I just say that this is the way the world is ;) Look at French, Spanish or German systems for example (sorry, not sure about Dutch...). There are things like öäüáéî and the like. You probably don't get them right on this email because they are 8 bit chars. Those chars very often make it into syslog messages, which then violate the RFCs. It is not a big issue, as almost all syslog implementations simply allow 8 bit characters but if you look at this from a strict point of view, it is a violation. The same goes with Japanese installations. I pick Japanese, because we have some first-hand experience with our products. Japanese customers really love to be able to read what their system is telling them, and this in native language. So, yes, I think there is need for i18n in syslog ;) > >E.g. a Unix-kernel, of the RT core of a router is will be written in >"englisch-C" there is no need for i18n. Often, there will be no room >for ir either. However, it's need logging. UPD-syslog will do fine! Even in this case, beware of at least the local language names - they often turn out to have 8 bit chars. > >My idea is to think about "syslog" as a concept, without (hard) >limit's. It is a header with a prio, a timestamp etc and "a short line >of message". > >With UDP syslog, the line is upto 1K (Biut face it, I hardly see line >abouve 80 chars. So with i18n, 3 thime 80 will fit. If I look at e.g. the WELF format (webtrends), you can quickly have more than 80 chars. The same definitely is the case of Windows logs. >TCP syslog, syslog-"whatever" doesn;'t need to inherite that limit. >Just the concept. But that doesn't mean UDP-syslog can't bee used any >more! Here I totally agree. Everyone pls face it: I don't expect UDP syslog to disappear any time soon. Especially with low-end devices, you can consider yourself lucky if they at least support it. I can envison they will change to a tcp based approach any time soon. So there is need for it. Rainer
