> -----Original Message-----
> From: Alfonso De Gregorio
> Sent: April 05, 2001 8:53 PM
> To: Albert Mietus
> Cc: [EMAIL PROTECTED]
> Subject: Re: Comment on syslog-syslog-07
> > I think the RFC becomes a lot clearer when the syslog message is
> > described in three parts, instead of as 2 parts.
> > Now, the message is described as (informally)
> > syslog := PRI MSG
> > PRI := "<" up-to-3-digits ">"
> > MSG := [ 3-header-parts ] free-text
> > Then, in text is explained that the "3-header-parts" (timestamp,
> > host and tag) are more or less default [my interpretation]
> >
> > I suggest to rewrite this, so that the message consist of 3
> parts, of
> > which 1 is optional. Like (again informal)
> > syslog := PRI HEADER CONTEXT
> > PRI := "<" up-to-3-digits ">" -- as before
> > HEADER := "" -- empty, not
> recommended
> > :or: 3-header-parts -- as before
> > CONTEXT := free-text
> > Basically, the "HEADER" part is inserted into the description
> > (notice: not to the protocol) This way, it becomes clearer how a
> > message is buildup (read: as it should be build-up).
>
> The aim of this Internet Draft is to describe the observed behavior
> of the syslog protocol. The distinction between two (or more) syslog
> message parts is useful when we think to who is interested to each of
> these parts. The description on code set, length and
> start/end characters
> for a given part aim to aid simply the syslog message parsing for
> collectors.
>
> 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.
As an implementor of both a sender and a receiver, I too would find it very
useful to have what Albert refers to as the HEADER separately defined - and
I would hope that this ID will be looked to by implementors as the basis for
generating and processing syslog packets. The key here is that this ID not
only provides guidance on what can be parsed, but what is to be placed in
the packet as it is being assembled. The reaons why I would find the
distinction of a HEADER useful are:
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.
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.
--
J. Gregory Wright
Senior Software Engineer
AT&T Information Security Center
Email: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
Voice: 301-815-9842
