> It's a problem if the message cannot be parsed and is dropped. Agreed, but you now seem to be implying that this just happens because syslog, rather than mis

> It's a problem if the message cannot be parsed and is dropped. Agreed, but you now seem to be implying that this just happens because syslog, rather than misusing the tool. Earlier, you asserted "Plug any two syslog implementations and they won't work together" which I didn't bother to contradict, because it seemed like mere exaggeration. However, at this point, it seems like an extraordinary claim requiring extraordinary evidence. I have, of course, routinely, in my professional career, spanning decades, successfully used different implementations with each other, usually because (more than) one implementation is embedded and can't be changed to match what's on the servers. Exactly which syslogd implementations connected to each other over the network will fail to parse messages and drop them? > The two RFC are incompatible, then every implementation is slightly different I think you're reversing cuase and effect, especially given both the relatively late date of the earlier RFC in the timeline of Unix history, as well as its enduring popularity over the later RFC. > I am calling out your first post that syslog is lightweight, flexible and plain text. I don't believe you've addressed, in any way, the assertion that it's lightweight. Your challenge to its flexibility is, AFAICT, poor interoperability of only the network protocol, which you haven't backed up with evidence. Even then, that's a weak refutation of the flexibility of the mechanism overall. Your challenge to its being plain text is, again, primarily based only on network protocol, and, even then, based on a widely-unimplemented RFC. > syslog suffers from serious issues. This may be responding to an implied strawman, that syslog somehow perfect or ideal for all use cases, which, of course, I never said. In fact, being plain-text could be considered a "serious issue" for some telemetry.