> -----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
