[prev in list] [next in list] [prev in thread] [next in thread] 

List:       syslog-sec
Subject:    Re: -international: trailer - escaping chrs
From:       Devin Kowatch <devink () sdsc ! edu>
Date:       2004-01-29 21:21:02
Message-ID: 200401292129.i0TLTuu8012726 () willers ! employees ! org
[Download RAW message or body]

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: owner-syslog-sec@employees.org
> [mailto:owner-syslog-sec@employees.org] On Behalf Of Rainer Gerhards
> Sent: Thursday, 29 January 2004 6:43 a.m.
> To: Anton Okmianski; syslog-sec@employees.org
> Subject: RE: -international: trailer
>
>
> > -----Original Message-----
> > From: Anton Okmianski [mailto:aokmians@cisco.com]
> > Sent: Wednesday, January 28, 2004 6:19 PM
> > To: Rainer Gerhards; syslog-sec@employees.org
> > 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
devink@sdsc.edu

[prev in list] [next in list] [prev in thread] [next in thread]