Since syslog messages are usually logged to a flat file, and each line in the file is terminated by CRLF (or just LF or CR), I think we should escape all control chrs in the message text. Currently Kiwi Syslog does this by converting it to <013> type format. It would be good if we could reach a consensus on the best way to do this for -protocol. Having control chrs like CR and LF in the message text would break a lot of log file parsers.
We could use \#HX or \#HXHX for double byte chr sets. The advantage to using <013> is that you have a start and end delimiter. So if we used \#HX then it would either need to be fixed length, or followed by a known delimiter (space). This means that the message can be converted back at a later date if required. Do we mandate that -protocol messages MUST not contain ASCII values less than &H20 ? Or do we say that the receiving syslog daemon is expected to escape all invalid chrs. Personally, I can't see a reason why you would want to use chrs < &H20 in a message. Can anyone think of a good reason? Cheers Andrew -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rainer Gerhards Sent: Thursday, 29 January 2004 6:43 a.m. To: Anton Okmianski; [EMAIL PROTECTED] Subject: RE: -international: trailer > -----Original Message----- > From: Anton Okmianski [mailto:[EMAIL PROTECTED] > Sent: Wednesday, January 28, 2004 6:19 PM > To: Rainer Gerhards; [EMAIL PROTECTED] > Subject: RE: -international: trailer > > Rainer: > > > as I am editing -international, I noticed that the TRAILER > > specified may be worth looking at. Now that we do not need to > > remain backward-compatible, I would opt to have a simple > > tailer in the message. It was defined as: > > > > SYSLOG-MSG = PRI HEADER MSG [TRAILER] > > TRAILER = [CR] LF > > > > While the trailer is not strictly necessary to form the > > message, I think it is quite a good sanity check if the > > message looks OK. > > IMO, if we think the trailer is useful, then it should be required. > Making it optional only opens possibilities for misinterpretation. > Also, having to deal with two potential variations of trailers is not > optimal although I understand the OS differences. Yet another > reason to > drop it. Agree... how about this SYSLOG-MSG = PRI HEADER MSG TRAILER TRAILER = LF I see the benefit in a way to verify (a little) that we actually have received the full message. And don't take the LF as something I insist on. It may be any value that is not allowed in MSG itself. As it looks, LF may not be a good candidate for this... > BTW, previous syslog server implementations (Solaris, for instance) > allowed line breaks inside messages. oops ... really? > I think there was some > discussion > about this before, but I am not sure what we concluded. I have used the search engine on my private archive (which seems to have an issue with returning to the right threading view). I think this was the discussion: http://www.syslog.cc/ietf/autoarc/msg00865.html I went quickly over it, and it was not resolved. However, I said that LF in messages are a bad thing and nobody objected ;) I am still of this feeling, because I see a lot of issues on the log parser side if we allow multiple lines for a single message. > Should we allow > them in -protocol? > > If not, I think we need some other mechanism to handle such > messages to > ease migration to -protocol. For example, we could extend > the scope of > message fragmentation for this purpose. > > Here is Solaris example of what appears in the log file if > sending "\n": > > Oct 11 22:14:15 myhost2 su: Message with line break\nbefore end ah, ok, so solaris does this processing, obviously when writing to the file. That would mean that we would need to apply escaping to the free form part of the text, too. Not a bad idea... Especially as I think the \x form will seldomly hit sombody. Maybe we should also allow \#HX with HX being the byte to be represented in hex. Doing so opens up the ability to actually send anything as printable text in a standards way. Sounds like a good thing... Any comments on that? Rainer
