RE: [Liblogging-users] liblogging Cooked-initiator

[Rainer G. <rge...@hq...>]

MC,

I should have waited some more minutes before hitting send ;) Anyhow...=20


> This function (srSLMGFormatRawMsg) also adds a RAW header to=20
> the message which is no use for COOKED messages. RAW profile=20
> uses BSD syslog headers whereas Cooked uses the attributes of=20
> the "entry" XML element. I obtain a message with an "entry"=20
> element with the timestamp, severity, hostname, etc and in=20
> this element, I have a RAW message with, again, the=20
> timestamp, severity, hostname and so on. I think the profile=20
> used should be matched in that function and in the cooked=20
> case, no header should be added. (What about calling it=20
> srSLMGFormatMsg?) The other solution would be to externalyse=20
> the tasks needed for RAM & Cooked profiles from that function.

I am following the recommendation from RFC 3195 here:

####
The character data for the element is the unstructured syslog event
   message being logged.  If the original device delivers the message
   for the first time via the COOKED profile, it may have any structure
   inside the CDATA.  However, for maximum compatibility, the device
   SHOULD format the CDATA of the message in accordance with Sections
   4.2.1 through 4.2.3 of [1].
####

From my personal view, I think this recommendation makes sense as it
allows easy transformation from COOKED messages to RAW or "plain" RFC
3164 syslog. This is especially important when messages are digitally
signed (syslog-sign is lurking at IETF syslog WG for quite some while
and will come out in the future...).

Rainer