Sharon, I just integrated your suggestion into the draft. During that, I noticed a small but eventually important thing. You wrote:
> 2) Truncation by dropping SD-PARAMS; An SD-PARAM is a parameter of an SD-ELEMENT. It describes this element. I think we should not drop a single parameter but rather the full SD-ELEMENT if we need to truncate. Otherwise we can run into subtle complexities. As such, I have changed the text as follows: 1) No truncation 2) Truncation by dropping SD-ELEMENTS; 3) If 2) not sufficient, truncate message Please let me know if that is NOT what you would like to see. Sorry, I didn't spot this until I cross-checked it with examples. Rainer > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Sharon Chisholm > Sent: Monday, April 04, 2005 3:17 PM > To: [email protected] > Subject: RE: [Syslog-sec] syslog message truncation > > 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 > _______________________________________________ Syslog-sec mailing list [email protected] http://www.employees.org/mailman/listinfo/syslog-sec
