Albert, > > > > I would, however, like to extend the core syslog format to > > > support > [...] needs to send a larger message > > Well, I know Microsoft does not necessarily do it smartly. Many > > > ------- BEING LOG ENTRY ;) ----- > [deleted about 3k] > > -------- END LOG ENTRY ------ > > > Still objections? > > I think it is "silly" to make log-entries of this size. BUT, it seams > to be happening. Therefore, I agree with Rainer; we should support it. > And so, we should do it in -sign.
I think -sign already does support oversize messages ;). Let's assume we take the route currently outlined by -international. In there, we have a cookie-based fragmentation method. I don't have the time to create a full, correct example, but this is basically how a 3 key message would look (all inside MSG part). Let's assume the syntax would be COOKIE FRAGNBR MSGFRAGMENT So it would be: @#intl 0 first 1k @#intl 1 first 1k @#intl 2 first 1k This would be 3 syslog messages if you look at it from the -sign perspective. As such, you can sign them as usual. Only the collector can combine them or the reporting engine (maybe the preferred method!) combines them. Of course, if the collector combines them, it must store a separate raw log for offline verification - but there is little complexity involved in doing so. And you probably need to do it anyhow, as most currently existing reporting engines won't work on raw (and I am not sure if it would be a good idea to make each individual reporting engine understand the available syslog message formats...). I expect the vast majority of message to travel within a single packet. The way -international supports oversize messages is meant to be very light and not to put a burden on the usual case (small messages). But it provides a mechanism to support oversize messages in the rare cases they appear. At least, this is how I hope it works ;) Bottom line: I don't see any need to change -sign to support oversize messages. Rainer
