Banzsi: I agree truncation does not solve the issue - that's why I don't want to over-design it.
Splitting is an option I'd leave to application-layer running above syslog. It is not precluded. Just a matter of another RFC with extra sd-elements. If we do fragmentation in syslog transport/protocol, we are re-inventing IP & TCP. We went down the path of defining special sd-elements for this once, but decided that in most cases increasing max acceptable message size on receivers and using appropriate transport is a better solution for many deployments. I'd propose we do truncation as raw octet cut-over, but define an optional sd-element for msg-length (in octets?), which people can use to know if there was truncation. However, this would mean we would allow a proxy to legitimately send malformed messages. Well, a receiver has to handle those somehow coming from the original sender anyway. It is not ideal, whichever way you slice it. Anton. > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Balazs Scheidler > Sent: Thursday, January 12, 2006 5:07 AM > To: Rainer Gerhards > Cc: [EMAIL PROTECTED] > Subject: RE: [Syslog] Sec 6.1: Truncation > > On Thu, 2006-01-12 at 10:45 +0100, Rainer Gerhards wrote: > > Anton & all, > > > > You have good points and I have to admit I am still > thinking what is > > the best way. I would appreciate if some other WG members could > > express their thoughts... > > My pragmatic view is that overly long messages should be > split instead of truncated. Of course splitting rules are > similar to truncating rules in a sense, but the question of > generating the syslog header also comes up, e.g. > > <16>Jun 12 13:45:54 host app[12345]: This is a too long message > > should become: > > <16>Jun 12 13:45:54 host app[12345]: This is a too... > <16>Jun 12 13:45:54 host app[12345]: long message > > This way we don't lose information while still limiting the > message size. Of course this will still confuse log analysis > applications but it can be solved simply by lifting the > message size limit if that is configurable in the syslog application. > > Maybe we should indicate in an SD-ID that message truncation > happened so there would be no ambiguity. > > Another question whether we allow relays to modify the SD-ID > part of the message or it must be done by the sender alone? > > -- > Bazsi > > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
