Darren: > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Darren Reed > Sent: Wednesday, November 23, 2005 9:09 AM > To: Moehrke, John (GE Healthcare) > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: [Syslog] RE: Message format > > > To all, > > > > The view that syslog must only be used to transport "human readable > > syslog messages" is disturbing. Is this the view of the syslog > > community? > > At present what we're concerned with is a logging facility > that does generate and consume human readable messages.
How do you define "human readable"? Is assembly code human readable? :) Maybe you implied it should be limited to printed characters... well any octet can be represented in print in some shape or form (say by hex), and I thought it is out of scope how stuff is printed, displayed or stored on disk for the on-the-wire protocol. If you limit it to "language" characters, you don't really want to exclude control characters such as tabs. I really don't think there is a good reason to exclude any octet in the payload. It would be like saying you can't send certain octets in email (including binary attachments) because it must be human readable. Well, let the two sides figure out what is readable to them and just transport the payload with appropriate agreed-upon header. At a minimum, I hope that if we put terms like "human readable" into the charter, we would be clear about what they mean. Also consider that programmatic parsing and interpretation of syslog messages is common-place today and must continue. For example, gazillions of systems (home grown and commercial) have been built around Cisco's use of syslog to do automated fault detection, correlation, etc. Use google to find examples. In summary, I am not comfortable with "human readable" restriction going into the charter. Thanks, Anton. > > At some point in the future, when we have agreement on the > human readable version, then we can consider what to do with > messages that aren't human readable. > > So while I accept your assertion, addressing it is out of > scope for the current discussion. We have smaller fish to > fry, first, before attempting the big ones. Trying to solve > "all the problems" is what got this group into the situation > we are in now. We need to take a step back and focus on > resolving smaller and more well defined problems before > looking at a "grand unified logging protocol" (GULP). > > Nothing lasts forever, not even standards. > > Darren > > _______________________________________________ > 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
