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
