For escaping characters I would suggest using a comment escape syntax. For example, C does character escapes as \(o|x|)DDD, or if you want a begining and ending, perhaps the XML escape &#XXXX; (I think). Anyway the point use an escape sequence that is common rather than making up our own. It just confuses people less.
Also, using <XXX> will make some wonder what XML/HTML is doing in their log messages :) On Thu, Jan 29, 2004 at 10:43:15AM +1300, Andrew Ross wrote: > > 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 > > > > -- Devin Kowatch [EMAIL PROTECTED]
