Like Anton, I would like to ensure that RFC.new uses a new, specific message format, that does not use the RFC3164 timestamp.
The [] or <> bracketing system with some sort of escaping will work for me. My expectation is that if a syslog relay/collector receives a RFC3164 (or any non-RFC.new format) message, that it will modify it and send it on (or log it to disk) in the RFC.new format. It sounds like we are all on the same wavelength, but saying it in a different way. Cheers Andrew >Anton wrote... >I would rather leave RFC 3164 as open as it is. But in RFC.new define a >strict format we want new applications follow. So, if somebody says that >their syslog client is RFC.new-compliant then it means it fires messages >in one precise format we know is desirable. And not, maybe a new format, >but maybe also some old one like with old timestamp. Otherwise, we are >allowing an implementation to use an old format and claim it is >RFC.new-compatible. I think it is not desirable. This would require me, >for example, saying to our development groups that being compliant with >RFC.new is not enough. I would also have to ask for implementations of >a specific timestamp format, for example. I'd rather not have to do >that wherever possible. It creates ambiguity around the RFC.
