Rainer: OK. Here are a few of my imagined uses of the MSG with mixed text and binary data.
1.) With the option to include binary data in the MSG, a new set of diagnostic messages can include some system internal data structure values of concern for analysis. The beginning text in MSG will state detailed description of the following binary data structure values. With proper tools provided, the binary data structure values can be examined in great details at the receiving end. 2.) Or the MSG can be used to capture the original incoming packet data detected containing certain pattern. 3.) We can also include some voice data (binary) in MSG for certain situations. 4.) It can become backup route for SNMP traps because it can now carry text and binary data in MSG. The possible usage is basically up to device vendor's imaginations. But if you only allow for text data because of the concern at hand over NULL character, then the door is shut. With potentially rich feature sets to be imagined and to come with this binary-data-capable MSG, the syslog message receiver will have to be upgraded to be able to enjoy the benefits. I will leave it to sales/marketing people to convince the customers so NULL sensitive syslog message receiver will not be in the way. Thanks, Steve > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of Rainer Gerhards > Sent: Thursday, November 24, 2005 3:50 AM > To: [EMAIL PROTECTED] > Subject: RE: [Syslog] New direction and proposed charter > > Steve, > > no reply, but a question very important to me. What do you consider a > valid use case for the US-ASCII NUL character inside MSG? If I had a > good sample, I'd probably have a better time understanding why this is > important... > > Rainer > > On Thu, 2005-11-24 at 11:48, Steve Chang (schang99) wrote: > > Rainer: > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] > > > On Behalf Of Rainer Gerhards > > > Sent: Thursday, November 24, 2005 1:25 AM > > > To: Balazs Scheidler > > > Cc: [EMAIL PROTECTED] > > > Subject: RE: [Syslog] New direction and proposed charter > > > > > > > On Thu, 2005-11-24 at 09:36 +0100, Rainer Gerhards wrote: > > > > > Anton: > > > > > > > > > So I wonder if it wouldn't be wiser to accept that CLR here > > > > and disallow > > > > > NUL. After all, I can not see a valid use case for it > > > > either... (in the > > > > > sample you provided it honestly believe the sender should > > > > not send a NUL > > > > > octet but a "\u0000" string). > > > > > > > > > > > > > \u0000 is a NUL octet at least in its canonical encoding. > > > > > > OK, looks like I need to dig up the ASCII table. My fault I didn't do > > it > > > in the first place. > > > > > > Anston's sample was > > > > > > ...MyApp pid123 MALFORMED_INPUT: Bad input received from client: > > > [aaa\u0000] > > > > > > For simplicity, let me strip the rest and just look at that part > > > > > > \u0000 > > > > > > I think the sender of the sample message should not encode it as > > > > > > NUL (0x00) > > > > > > but instead as > > > > > > 0x5c-0x75-0x30-0x30-0x30-0x30 (\-u-0-0-0-0) > > > > > > Encoding it as NUL in an otherwise human-readable message makes no > > sense > > > to me. > > > > > > > From the perspective of formatting a piece of device internal raw data > > into an outgoing syslog message and considering the CPU cycles needed to > > encode a NULL character into some other form to keep the whole MSG > > intact, > > I would say prepend the length of MSG (or say, add a fixed 4 digits byte > > length of the MSG between SD-IDs and MSG) will be much easier for the > > sender. With this, I think the new IETF syslog compliant receiver > > should also have easier time fetching in the complete MSG, regardless > > it's a plain text, XML-formated, or even binary data. > > [** side note: a fixed 4 digit MSG length can handle up to 9999 bytes. > > Big enough for foreseeable future. Also, the first MSG can be appended > > with other feature specific information before it gets sent out. And > > hence updating the final MSG length can be easier.] > > > > As to what will happen to the old syslog receivers receiving the message > > will NULL character? The message will probably be cut short right at > > reading the NULL character as you have explained. And I don't think > > there will be a good compromised solution for it. > > > > At the sender side, the overhead in checking for a NULL character in any > > of the incoming raw message and encode it to other form is just not > > practical. I would rather not have to pay that overhead if possible. > > Besides, if mandated, you will be limiting how MSG is to be used. > > > > I would say it should be sufficient to just explicitly point out the > > danger of having the NUL in the MSG part in the new IETF syslog > > protocol. > > And you can be kind to add some suggestions as to how the syslog message > > initial sending device can choose to do to handle this situation > > themselves. > > Vendors should make their own decisions on this issue. > > > > With this caveat, we get to keep the flexibility of having the MSG part > > in plain text, or in binary for the IETF syslog protocol. > > > > It's tradeoff for WG to debate. > > > > > > > I am questioning if there is any legitimate case where an actual NUL > > > needs to be part of MSG. > > > > > > > UTF-8 allows > > > > the same character to be encoded in multiple ways, see a > > > > description on > > > > the encoding format: > > > > > > > > http://www1.tip.nl/~t876506/utf8tbl.html > > > > > > > > And I think it would be wise to require the canonical encoding to be > > > > used and treat all other encodings of the same characters as errors. > > > > this is a large can of worms, lot's of security problems arised from > > > > this issue. (see the IIS problems couple of years ago) > > > > > > "Shortest possible form" thanksfully is already required in > > > syslog-protocol-15. > > > > > > Rainer > > > > > > _______________________________________________ > > > Syslog mailing list > > > Syslog@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/syslog > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog