On Fri, Apr 06, 2001 at 01:39:58PM -0400, Wright, Joseph G (Gregory), GOVMK wrote:
> > Receivers should not be interested in the MSG part of a given
> > syslog message. In fact, there are "no set requirements on
> > the contents of
> > the MSG as it is originally sent from a device"; to have
> > fields such as
> > TIMESTAMP or HOSTNAME is simply racommended while composing
> > a message.
> > So, receivers shouldn't rely on any contents at all of the MSG part.
> >
> > Relays and collectors, instead, are both interested to the PRI part of
> > received syslog messages.
>
> Actually, relays do look at the TIMESTAMP field of the MSG element (c.v.
> 4.2.2, Relayed syslog Packets). If the relay is to relay the syslog packet,
> it must:
>
> 1. Check to see if a valid TIMESTAMP is the first field of the MSG.
> 2. If there is a valid TIMESTAMP, the entire packet MUST be forwarded
> unchanged.
> 3. If there is not a valid TIMESTAMP, the relay MUST add a TIMESTAMP
> followed by a space character.
> 4. If (3) is true, the the relay SHOULD insert a HOSTNAME and a space.
>
> > Separating the MSG part into more parts do not aid the parsing. So
> > there is no reason to make this split.
[...omissis...]
> 1. The contents of HEADER have distinct content and format guidelines,
> compared to that of MSG.
> 2. It could be made clearer in the definition of the HEADER that the HEADER
> is created by a sender, examined and possibly created by a relay, and may be
> totally ignored by a collector (is there a restriction that prevents a
> collector from being capable of acting on the non-PRI portions of the syslog
> packet?)
> 3. For implementors of non-human consumers of the syslog packets received
> and logged by collectors, it more clearly identifies the "standard" (sorry)
> fields within the packet that can be looked for and parsed by the consumer.
There is no restriction at all that prevents a collector to act on non-PRI
parts of a syslog message. However, to look at any expected content of a packet
is a plus; in fact, the described parts are highly RECOMMENDED but not required.
Collectors must be implemented to a have a "stock" behavior that don't
rely strongly on syslog messages contents.
For the same reason, also relays (as you correctly specified) when they don't
find a valid TIMESTAMP, add their own one to the message (and with it
preferably also the hostname).
> I would actually go so far as to say that a more formal syntax description
> would not be out of line, as an aid to packet assembly and parsing. And yes,
> I could probably be dragged into helping with that.
Please, feel free to propose a formal syntax.
Unfortunately we are describing the expected behavior of syslog, that is
far to be either a protocol with a not diversified syntax of its past
implementation, or the dreamed protocol for event notificatication messages
logging designed with security and robustness in mind.
alfonso
