Rainer: I agree backwards compatibility is a messy subject. I think the proposal on the table now is to do just <PRI> with the hope that this allows old receivers to at least process message with appropriate severity/facility. Say long to a different file. For everything else, all bets are off.
My experience with Solaris/Linux receivers shows they would accept a message with good PRI and then junk. They just append their own timestamp. But I agree, this won't guarantee backwards compatibility with any receiver because receivers are not standard at this point. Achieving interop with something that is not standard is a tough problem. If people want old <PRI> in there, I am ok with that. But I agree with you, let's not be naïve about what level of interop this would achieve. If that very basic level is useful to people - fine. But there is no grand goal of full backwards compatibility here. We have to be clear about that in the charter. To the specific issue... UTF-8 encoding of basic ASCII is the same 7-bit ASCII code. So, if new sender only sends a subset of characters allowed by RFC 3164 and encodes them as UTF-8, it will look exactly as old encoding. So, I think that part is backwards compatible for the subset of characters supported by old receivers. Thanks, Anton. > -----Original Message----- > From: Rainer Gerhards [mailto:[EMAIL PROTECTED] > Sent: Monday, November 21, 2005 3:45 PM > To: Anton Okmianski (aokmians); Chris Lonvick (clonvick); > [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: RE: [Syslog] New direction and proposed charter > > Anton, > > Please read my message in the spirit of the question on > backwards compatibility I posted after the initial reply. > Sorry for not telling this together with the initla reply. > > I too find it not suitable to support a horrendous number of > encodings, but if we really want backwards compatibility, we > must do it - simply because it is currently done. > > All it boils down is how important backwards compatibility is. > > As of the language, I am not sure if it will be useful to > have this. For example, what about a message that contains > mixed language strings (english/some local language) is not > uncommon. I do not see any benefit that is worth this trouble. > > Rainer > > > -----Original Message----- > > From: Anton Okmianski (aokmians) [mailto:[EMAIL PROTECTED] > > Sent: Monday, November 21, 2005 9:32 PM > > To: Rainer Gerhards; Chris Lonvick (clonvick); [EMAIL PROTECTED] > > Cc: [EMAIL PROTECTED] > > Subject: RE: [Syslog] New direction and proposed charter > > > > Rainer: > > > > > > Encoding has been discussed and we have agreed upon > > > US-ASCII and UTF-8 > > > > in appropriate places. Could we add a language tag as an > > > element in > > > > an SD-ID to indicate the language of the MSG? > > > > > > If so, we should include the *character set* not the language. In > > > respect to existing implementations, that would also be > usefule. We > > > should strongly consider to allow (but not recommend) other > > > encodings, too (like popular JIS or EUC). I also posted > this in my > > > previous mail. > > > > By character sets, do you suggest the use of the various > > locale-specific encodings instead of using Unicode with some UTF-8? > > > > I think that horrible legacy of gazillion local-specific encodings > > should be avoided at all cost! It is a dead-end. > > Unicode resolved that issue -- we should stick to it. I > thought this > > was an accepted direction at IETF. It is in the industry too. > > > > If I understand correctly, Chris was proposing a mere indication of > > the language(s) used, which could be useful to the person analyzing > > the message. I don't think Chris was proposing to do > something instead > > of UTF-8, which covers all of Unicode, which in turn covers all > > languages. Or did I misinterpret? > > > > Thanks, > > Anton > > > > > > > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
