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

From: "Rainer Gerhards" <[email-masked]>
Date: Wed, 30 Nov 2005 14:17:55 +0100

Andrew,

> That sounds good to me at this stage, and it keeps the door 
> open. I would
> prefer to see all binary data encoded in some "safe" format 
> like base64. It
> just makes logging the data to file much easier. For 
> instance, if the binary
> data contained a LF character, when it was logged to disk, it 
> would end up
> as two separate messages when opened in notepad etc.

While I too prefer a "safe" format, I would not like to outrule another
one. Maybe later... (we *need* to finish this I-D...). How it is handled
when writing to disk is beyond IETF. I would escape it then - but that's
up to the implementation.

> Also, if we are to transport syslog over TCP at some stage, 
> we need to keep
> a delimiter character free from use in the message. Again, a 
> LF would be a
> good choice for this delimiter.

Here, I disagree. I think we can not set aside a character for this. If
we go for TCP, let's do octet-couting. Its reliable, efficient and
proven. Anyhow, we are not yet doing a TCP mapping, so I suggest we save
this discussion until later.

Rainer
PS: sorry for trying to focus on the immediate needs. But I think we
really need to finish something...

> Cheers
> 
> Andrew
> 
> 
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]
> On Behalf Of Rainer Gerhards
> Sent: Wednesday, 30 November 2005 9:26 p.m.
> To: [email-masked]
> Subject: [Syslog] #3 NUL octets, #4 binary data, #8 octet-counting
> 
> 
> 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
> 
> 

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

---

From: Chris Lonvick <[email-masked]>
Date: Wed, 30 Nov 2005 06:08:17 -0800 (PST)

Hi,

Let's keep in mind that syslog-sign will transport binary signatures.  In 
that, the authors are proposing to use base-64 encoding.  I agree with 
Rainer that we've provided enough means in syslog-protocol so that may be 
accomplished.

As Rainer says, let's focus on getting syslog-protocol finished.  :)

Thanks,
Chris

---

From: Darren Reed <[email-masked]>
Date: Thu, 1 Dec 2005 02:47:36 +1100 (EST)

> this discussion until later.

Why not use LF?

It will work.  There are syslogd implementations about that use LF as
a record delimeter.  In other emails you're saying "we must support
binary because some people are going to use this".  Now we've got people
that support LF as a record delimeter already but you don't want to
take this into account.

Why does what one vendor is going to do mean more than what other
vendors are already doing ?  Is there bias here somewhere ?  Do you
have any particular preference based on work you've done or through
some sort of affiliation ?

If you want to discount use of LF as a record delimeter then there
is no reason we must support use of binary because what vendors are
doing is obviously irrelevant.

Darren