hi Is silence consent on this one? I'm interested to know if we agree with this.
Thanks, Sharon -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chisholm, Sharon [CAR:5K50:EXCH] Sent: Wednesday, March 23, 2005 3:34 PM To: [email protected] Subject: RE: [Syslog-sec] syslog message truncation hi Ok. My current thinking on message truncation is that we want to encourage the dropping of the SD-PARAMS and the retention of the message text. This is the more unique bit and makes for much simpler truncation. We can add a bit to the header if we want or indicate that if the SD-PARAM list is blank, then truncation may have occurred. Ok. a bit in the header is probably better. So, the preference is 1) No truncation 2) Truncation by dropping SD-PARAMS; 3) If 2) not sufficient, truncate message 4) In the case that truncation cannot result in a valid message then dropping. Note that given the current truncation algorithm, this may not actually occur. Sharon -----Original Message----- From: Rainer Gerhards [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 15, 2005 7:42 AM To: Chisholm, Sharon [CAR:5K50:EXCH]; [email protected] Subject: RE: [Syslog-sec] syslog message truncation Sharon, > If truncation is required, then the point of truncation be determined. > If it is within the message text, then the truncation bit be set > within the message header and the message be sent with its reduced > size. If the point > of truncation is somewhere before the message text, then this > message be > discarded. I am not sure if it is appropriate to drop the message completely. At least the drop should be optional (maybe with a rule that the truncated message should not further be forwarded). I am concerned because I think we might loose vital information in this case. As an alternate approach, the "truncation information field" could have three values: n - no truncation occured m - truncation im MSG part s - truncation in STRUCTURED-DATA part that would convey enough information to the (ultimate) receiver so that it can decide how to act on a message. Comments? Rainer _______________________________________________ Syslog-sec mailing list [email protected] http://www.employees.org/mailman/listinfo/syslog-sec _______________________________________________ Syslog-sec mailing list [email protected] http://www.employees.org/mailman/listinfo/syslog-sec
