Hi,
On Thu, 17 Aug 2006, Balazs Scheidler wrote:
On Wed, 2006-08-16 at 12:32 -0700, Carson Gaspar wrote:
Escaping precludes no-configuration backwards compatibility, as no legacy
syslog-over-tcp code does escaping. So if you want to interoperate with
existing code, you must have a "don't escape or expect escapes" switch in
your code. If you're going to do that, just have a "LF mode vs byte-count
mode" switch. This whole backwards compat argument is bogus, iff we decide
to escape embedded LF instead of forbidding it. And I have yet to see
anyone argue for LF on any grounds except backwards compatibility.
As I said in a private mail to you, no we don't need that switch. LF is
escaped as a sequence of two characters '\' and 'n'. This way escaped LF
characters will not affect protocol processing, the only issue is that
LFs in the message will be written to the disk in a slightly different
format. But adding the fact that current TCP senders are not transparent
wrt LFs this is not a big deal.
- old sender - new receiver
=> works, because current syslog-TCP senders strip LFs off the
message, either they replace it with space or forward multiple messages
- new sender - old receiver
=> works, because the old receiver does not care about the "\n"
string in the message, although it will not unescape it when it writes
it to disk
What's going to happen with syslog-sign and/or other mechanisms that will
look at the packet and create a hash of it? It sounds like everything
will be acceptable if a new receiver gets it and does the re-conversion
before anything looks at the contents. However, an old receiver will
continue to keep the \n which will mess up syslog-sign. Is that correct?
Also, what's going to happen to a new receiver that receives a legitimate
"\n" as in an original message send:
<PRI>... BOM The offending characters are \n
Will the receiver convert that into LF?
Thanks,
Chris
_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog
