Richard, I read and re-read your mail... I maybe have it mistaken. I was thinking that you object the presence of strings inside the logs that you can't read and thus assign no meaning to it. Here, my answer still applies.
If, however, you are concerned that international characters / charsets will make your otherwise US ANSI logs unreadable, then I fully agree. What I propose is that all internationalization is within the limits of the current RFCs/Ids. This specifically means that all content must be 7 bit US ANSI only. To represent other charsets, a special encoding is needed, as there may be UTF-7, base64 or quoted-printable. In any case, a log file with sporadic Chineese message will still be readable even if you don't have the charsets at hand. Obviously, you won't be able to decipher the message, but the others ones will not be touched. Please note that even a Chineese speaker can not read them - they are encoded. So it is the (i18n capable) syslog collector's task to convert them into something readable. For example, the collector could store data in Unicode text log files. I hope this clarifies. Did I get closer to what you meant? Do you still disagree? Maybe I am overlooking something obvious... Rainer > -----Original Message----- > From: Richard E. Perlotto II [mailto:[EMAIL PROTECTED] > Sent: Monday, July 21, 2003 6:56 PM > To: Rainer Gerhards > Cc: [EMAIL PROTECTED]; 'Andrew Ross' > Subject: RE: Syslog Internationalization /UDP > > > I was not arguing in favor of locking the spec for English > text only, but > that the spec that we write must have conditions on how the > internationalization > is utilized so that it is all done consistently. I wanted to > bring up the > issue of having a multitude of character sets now available > and to ensure > that we are not compounding the problem. > > Because of the current market, you can assume that all > devices will be used > all over the world. This means that those in Argentina are > very likely to > be using devices from China. If the logs are set for > Chinese, then they will > be useless for those attempting use the logs. > > I just want to make sure that whatever we suggest it is > actually useful and > will work across the board. French just for the sake of > French is not > sufficient. > > > Richard > > -----Original Message----- > From: Rainer Gerhards [mailto:[EMAIL PROTECTED] > Sent: Monday, July 21, 2003 12:51 AM > To: Richard E. Perlotto II > Cc: [EMAIL PROTECTED]; Andrew Ross > Subject: RE: Syslog Internationalization /UDP > > > Richard, > > > 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. > > I would like to stress one motivation behind > internationalization. I think there are two motivations behind this: > > #1 local names > Local computer and user names are not uncommon at least in > the European environment (I am not sure about Asia). What > happens is we > have an otherwise English message, but it will pick up some > local e.g. system name with non US ANSI characters. Right now, this is > simply not supported in any of the standards. In reality, > most syslog clients (I > know) don't care and send 8 bit data. With I18N, we can > easily and "cleanly" include these local characters into our language > stream. > > #2 localized messages > In my point of view, this is radically different from #1. > Here, the whole message is local text and English is > potentially totally > absent. The motivation behind this is obviously to make the > message understandable to some non-English speaking folks. I > agree that > this poses a big problem to log analysers - they must support > different languages in their parsing. However, it may not pose a > problem to human readers... > > I think it is very dangerous to assume that everyone in IT > speaks English and does so fluently. Granted, if you are with an > international vendor OR with an international organization, > chances are good you are not hired if you don't speak > English. But even > then, I guess (no real > knowledge) that if you are with a French multinational, you > may need to speak French as the official first language. > > However, as soon as you leave the multinationals, things > change dramatically. You may find it surprisingly how few > admins - even in > large organizations - do not or only very weak speak English. > I know this for sure for Germany and have the strong feeling it is > also the case for Japan. My experience also tells me it is > most probably the case in China, France, Italy and Spain. I don't have > any real-world backed experience with other countries, but I > assume you could easily extend the list. So I think we must be *very > careful* when saying that non-English messages pose a > problem. In fact, for those people, the English messages are > useless. And keep > in mind this goup of people is by far larger in size than the > "mutlinational admins". So I would not jump on the wagon to say "it > must be English to be good" (sorry for over-stressing the > point a bit too much - my intension is to make the point very clearly > visible). > > Given this philosophy, I honestly don't have any problem with > Japanese devices only emiting Japanese messages and German ones only > German. These message will make far more sense to those in > the native language environment. Even think about low-end home users > strugling with the routers... > > I think we should provide the necessary standard enabling > vendors to create such devices. Then, let them (or better: the market) > decide if it actually makes sense to them. Right now, we have > *no* standard and do not leave the vendor any option to do this in a > standards-compliant way. What happens? Everybody emiting > local messages does it in a non-conformant way. > > I firmly believe: We can't and shouldn't tell vendors and > customers their choice of doing logging. If they like local logs in > multiple languages, let them do it. If they don't do that for > good reasons, that's fine. But if we do not provide a solution to do > it, they'll do it their own (and vendor-specific) way. > Remeber: ultimately, it is not the ISO or IETF or evel local > government (and > least in the free world ;)) that tells them what the have to > do: they decide themselfs based on market needs. The only thing we can > do to get it in an interoperable way is to help them with a > standard. Fortunatley, really bad ideas are sorted out quickly in the > market ;) > > Comments? > > Rainer > >
