BEEP may or may not pay its freight, but I don't see it becoming available across the board --- including innumerable embedded gizmos and weird proprietary OSes --- any time soon.
On the other hand, if we started with syslog-as-it-is-today, added TCP transport, took off the line length limits, delimited "records" in the TCP stream with newline, and permitted (as an option) ISO 8601 / RFC 3339 timestamps[1] instead of the ambiguous and hard-to-sort ones currently standardized, I think we'd hit most of the essentials. Plus, with little effort, existing implementations could be frobbed to interop with it, and I think that spec would describe an existing mode of extended operation on many of today's enhanced syslog implementations. As for having to re-do auth, privacy, etc., it seems odd not to just standardize a TCP service and use SSL if encryption/authentication is desired. Especially since, in the huge-horking-central-logserver scenario, SSL would let you use commodity SSL accellerators to buy the needed performance. -Bennett E.g. 2002-12-17T11:49:39-0500 I have long argued that that "T" is ugly, but I'm strangely swayed by Paul Roberton's observation that it's a handy hint that someone's actually trying to honor the standard.
