Subject: [Syslog-sec] syslog-protocol

From: "Rainer Gerhards" <[email-masked]>
Date: Mon, 12 Jul 2004 18:18:49 +0200

Hi list,

I am more or less finished with my next edit (which hopefully brings us
very close to a final version). However there is one thing that I would
one again like to bring to the attention of the list - simply because it
is much that needs to be changed:

Anton suggested:
> I know you wanted to keep some resemblance of the old ad-hoc syslog
> format, but two separate fields for TAG would make life much easier
> then having to find the last [ and only if there is ] at the end.  If
> we make two fields, they would be APP-NAME (or PROCESS-NAME) and
> PROCESS-ID.  This is much more intuitive then describing it as static
> vs. dynamic. And this is what people are after in the end. We could
> allow for say "-" for unknown process ID. But I think requiring
> APP-NAME is a must. What do you think?

I responded:
>That sounds good - I actually did not have this good idea. If there is
>no objection, I'll change it to this in the next draft.

I am still of the opinion that this is a good idea - especially as it
also solves some parsing nightmare with the colon characters. It just
finally breaks the legacy TAG ... but that would be easily to re-create
in change a process needs to relay to a RFC 3164 collector.

So I, too, would opt for 2 "TAG" fields separated by SP. I'm not sure if
the above names would be the most appropriate, maybe TAG-NAME and
TAG-PID would be better to tie them back to the 3164 TAG.

I'd appreciate feedback on this issue. I definitely plan to submit the
next draft before the cutoff date at the end of this week.

Rainer
	
_______________________________________________
Syslog-sec mailing list
[email-masked]
http://www.employees.org/mailman/listinfo/syslog-sec

---

From: Devin Kowatch <[email-masked]>
Date: Tue, 13 Jul 2004 16:57:36 -0700

> in change a process needs to relay to a RFC 3164 collector.

With out actually verifing anything.  My experiences on Linux and
Solaris suggest that it may not matter one way or the other.  Both
syslogd's only parse the message enough to add a time stamp or insert
the host name after the time stamp.

IIRC, RFC 3164 only allows something like alphanumerics in the TAG
field and everything else is considered the message/content anyway.  I
believe this is the reason that SDSC Syslog will consider [<pid>] as
part of the content.

The only area in which it may cause problems is that many existing
syslogd's will write out the message more or less as recieved, which
may cause syslog log file parsers to break.  But anyone who writes that
sort of thing should be fairly used to it breaking :)

-- 
Devin Kowatch
[email-masked]