Quoting Robert Webber ([EMAIL PROTECTED]) on Tue, Oct 19, 1999 at 06:26:23PM -0400:
> At 02:06 PM 10/19/1999 -0700, d wrote:
> >I thought chris calabrese might mention this (he sent it to me), but
> >another nice feature to have would be having regexp support. (Various
> >places it could be.) Having something like what tcp-wrappers have -
> >hosts allowed & denied - would be nice as well.
> >
> >Mind you, I've never worked on a protocol, so I'm not really sure how
> >to do this.
>
> Other than specifying the contents of a message in the new protocol to be
> easy to parse with a regexp tool, there's not much you can do about regular
> expressions in a protocol specification.
>
> I think that "messages should be regular in format and easy to parse" is a
> reasonable requirement, though. This might reflect into fixed-length
> fields, or labelled fields, in the protocol specification.
>
> Actual discussion of how to implement regexp or host allow/deny would seem
> to be a matter of, er, implementation, not protocol.
How about specifiying a standard set of tags that should be there. When
receiving from an oldstyle source, the new syslog would log or forward it with
a tags saying oldstyle so that we can still use the old stuff and have an easy
way to specify new things. Those tags come to my mind immediately:
ot: Old text record / free form text record (this is always the last tag)
st: Original senders time stamp
si: Original senders ip
sk: Original senders key (whatever this turns out to be)
sh: Original senders hash of the message it sends
fi: Forwarders ip (there mitght be multiple)
ft: Forwarders time stamp
fk: Forwarders key (whatever this turns out to be)
Each tag is preceded by a space and there should be no space after the colon.
Apart from the free form record no field can have text that looks like a tag.
maybe a bit simplistic...
cheers
afx
--
SuSE Muenchen GmbH Phone: +49-89-42769-0
Stahlgruberring 28 Fax: +49-89-42017701
D-81829 Muenchen, Germany
May the Source be with you!
