Steve: Sorry to be blunt: this is *faaaaaaaaaaar* bejond what we currently try to acomplish. I guess this should be defined in a smime to syslog mapping document. I am just a bit concerend about your proposed limit of 9999 octets. I am not sure how much voice will fit into it...
Honestly - this is no payload for syslog. I also see no point in SNMP backup. Some people might find that some of the samples are actual valid use cases, and I may become convinced over time. But - to say it with Darren - we have smaller fish to fry today ;) I also do not find it very consistent to vote in a meeting for backwards compatibility and then ask on list for a syslog revolution... Rainer > -----Original Message----- > From: Steve Chang (schang99) [mailto:[EMAIL PROTECTED] > Sent: Thursday, November 24, 2005 8:33 PM > To: Rainer Gerhards; [EMAIL PROTECTED] > Subject: RE: [Syslog] New direction and proposed charter > > 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
