[Syslog] Legitimate \n or byte-counting

Hi, If we use LF-escaping in syslog messages, what's going to happen if a legitimate \n is sent by a sender? An example would be: PRI... BOM The offending characters are \n Will a receiver convert that into LF? If that's the case then we should not be using LF-escaping. We need this

Re: [Syslog] WGLC: protocol

The only comments I would add are - p.18 suggest replacing 'ABNF %D92' by 'ABNF %d92' - 6.4 suggest ' a meta SD-ID' for 'an meta SD-ID' - 8.1 suggest replacing. 'security issues bound with UNICODE' by 'security issues with UNICODE' or 'security issues bound up with UNICODE' - On ITU

Re: [Syslog] byte-counting vs special character

inline tp - Original Message - From: Anton Okmianski (aokmians) [EMAIL PROTECTED] To: David Harrington [EMAIL PROTECTED]; Rainer Gerhards [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, August 15, 2006 8:04 PM Subject: RE: [Syslog] byte-counting vs special character I second these

Re: [Syslog] Legitimate \n or byte-counting

--On Friday, August 18, 2006 7:35 AM -0700 Chris Lonvick [EMAIL PROTECTED] wrote: If we use LF-escaping in syslog messages, what's going to happen if a legitimate \n is sent by a sender? An example would be: PRI... BOM The offending characters are \n Will a receiver convert that into

[Syslog] MIB document decision

Hi, I agree the terminology in the MIB document differs from that in -protocol- and should be updated to match the WG consensus on terminology. Here are a few things I spotted that should be fixed or checked: The references in the MIB are to RFC3164, not the current -protocol- document produced

RE: [Syslog] Legitimate \n or byte-counting

David, I have just now be able to poll my mail. I trust you as a co-chair that this time the documents will not be torn apart because of the missing backwards compatibility. Thus, I agree we should move to octet-couting, as there is more consensus to use that (and it is technically superior). I