Subject: [Syslog] #3 NUL octets, #4 binary data, #8 octet-counting

From: "Rainer Gerhards" <[email-masked]>
Date: Wed, 30 Nov 2005 09:26:04 +0100

Hi WG,

I have received notes via private mail telling me there seem to be some
existing (and eventually soon upcoming) valid use cases for binary data
in syslog. I think there is no point in arguing whether that's fortunate
or not. It simply looks like that's the way it is. I do not like the
idea of breaking existing use cases for syslog (because that will only
lead to implementors ignoring the spec and the story of syslog
inconsistencies continues...). As such, I think we need to provide at
least some minimal support for it (aka "not outlaw it").

At first, this implies that NUL octets may be present in the message.

I propose that we write text that discourages the use of NUL, but allows
it if needed. That text should also allow, but discourage, a receiver to
modify messages containing NUL. With that, we allow the use case, but do
not make it a "show stopper" for implementing compliant software. This
would also be pretty much in sync with what we currently find in
practice, so it is already expected behaviour. Finally, such text would
caution implementors that when NUL octets are present, chancs are high
that eventually present digitial signatures will be broken. In my point
of view, that's fair and efficient.

Chris proposal for #5 (character encoding) also provides an elegant
solution for binary data. We can use something like:

[enc="binary"]

or

[enc="base-64"]

I do NOT intend to specify this - I think it should be in the scope of a
separate document specifying the use of binary data. Then would also be
the right time to discuss all issues that arise out of it. For now, I
just would like to keep the door open.

Finally, I propose to extend Chris format so that the message size can
be conveyed. This has been brought up several times and I think a clean
solution is now obvious:

[enc="utf-8" lang="en" size="MSG-size-in-octets"]

MSG-size-in-octets would be the size of the MSG part (just that!) in
octets. Counting just the MSG part is sufficient, as the rest of the
message consists of fields properly delimited. The size is probably most
useful for binary data.

Please comment.

Rainer

_______________________________________________
Syslog mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/syslog

---

From: Darren Reed <[email-masked]>
Date: Wed, 30 Nov 2005 19:47:42 +1100 (EST)

> least some minimal support for it (aka "not outlaw it").
..

This is the wrong approach to take.

Furthermore, if 3164 is anything to go by, conveying of control characters
by the existing protocol is not well documented at present.

I think it is incumbant upon the WG to convey the message to implementors
that while it will listen to their needs and plans for implementation, it
is not up to them to choose which way this group proceeds merely because
they decide to provide a particular implementation.

..
> message consists of fields properly delimited. The size is probably most

What happens if the message is truncated?
What value is the message size really providing here?
If we have a natural EOR marker, LF, what do we need the size for?

Given that a syslog message is a single record, I don't believe that it
makes any sense to include a "size" parameter.

Darren