On Thu, Apr 05, 2001 at 10:35:54PM +0200, Albert Mietus wrote:
Hi,
> First, let me say that I'm sorry to not send this comment earlier, As
> I already noticed them in *-6 (which is the 1st I saw), but I hope my
> bits help.
Every comment is appreciated :-)
> 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.
Separating the MSG part into more parts do not aid the parsing. So
there is no reason to make this split.
> 4.2.4 (HOSTNAME size)
There isn't it ;-)
> I'm missing a hint/recommendation about the maximal size of the
> HOSTNAME part. Although this RFC will not specify the size of a
> hostname; its size is important.
> Maybe a RECOMMENDED on the max HOSTNAME length (how about 32 bytes)
> can be included. With this is added, a (recommended) minimal size of
> the CONTEXT can be calculated
HOSTNAME maximum length should not exceed the limits gived by the name
resolution protocol (eg. 256 characters for DNS, IIRC). The minimum length
can't be predicted a priori; nor, in my opinion, the maximum length should
have an "hard-coded" limit in the draft.
> 4.2.2, CONTEXT truncation, for relays
> Sometimes, a relay MUST truncate the package. However it isn't
> specified HOW this should be done, nor an advise is given. I think
> "removal of an appropriate number of bytes on the right-side" is
> meant. But this can be specified.
> On the other hand, removal of bugus HEADER bytes (so the left side of
> the newly CONTEXT field) is possible wiser.
If the packet has been expanded beyond 1024 bytes the packet MUST be
truncated to be 1024 bytes. This is true. But only relays are interested
by this when they adds a TIMESTAMP and HOSTNAME at the front of the MSG.
If a device receive a message whose length exceeds 1024 bytes, it MUST
NOT retransmit it.
The truncation "trim" a given message at byte 1024; any extra data that
_exceeds_ this limit is lost.
The addition of TIMESTAP and HOSTNAME fields by relays and the truncation
are the only processing allowed for syslog message receivers.
Any other type of processing for received messages is beyond the
scope of this Internet Draft, as stated om section 1.2.
Chris can certainly clarify better :-)
Sincerely,
alfonso
