> >That's nice to know, but it unfortunately is not an answer to the question I >asked. That question was not how a syslogd should handle NULs, but how a >library should handle NULs that a library user (app) potentially pushes to >it. My question was how to deal with that, and most importantly: is adoption >more important than technical soundness? > >This is within the context of log normalization and the CEE effort. For >syslog and rsyslog, the answer is already clear, you can find it in RFC5424 >(NULs permitted, but receiver is permitted to change them to a different >sequence). >
For technical soundness, all data should be handled as an octet stream. For usability, some libraries will want the raw binary, some will want the higher level types with encoded values. If we are worried about adoption, why not support both in the API? Handle the data as native octets under the hood (assuming a C like language) Allow the user to set a flag if they want the returned value to be encoded Though this approach only works for values... For things like the RFC5424 structured data, the name in name=value pairs cannot contain characters such as NUL. In my option, what to do if you receive a Syslog message with a NUL in the name, is the bigger issue _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
