Hi WG,
with this mail, I am again asking for some clarification. This question
may sound silly, but it actually is an issue to me. I am currently
implementing the COOKED server part.
The <entry> element (RFC3195, 4.4.2) contains a number of pre-parsed
entities, like facility, priority, tag, timestamp... The CDATA of the
entry element contains the full, unmodified syslog messages. This is
very useful, as, among others, it allows a -sign message to be
transmitted via 3195.
HOWEVER, I now have situations where wellformed messages actually
contain 2 PRI, tag, timestamp, ..., one in the entry element and one in
the raw message. I think this is the most common case. Question now, how
to handle this intelligently?
Should I return an error if the two values do not match?
Would it be wise to record both if I am a collector?
What should I do if they are different and I am a relay and need to
forward via e.g. 3195/RAW (because COOKED is not available on the remote
peer)?
One solution is:
If I am a relay and forward to another peer via COOKED, than the
duplicates can be preserved.
If I am a relay and forward to a peer via RAW or a 3164 syslogd,
- I will discard the entry paramters if the message
(CDATA) is wellformed
- I use the entry parameters if the CDATA is not well-formed
and thus modify the CDATA (much like 3164's relay roles)
If I am a collector, I either store
- both sets of values
- or just the raw CDATA
- or as described for a relay depending on the well-formedness
of the CDATA
I wonder if someone can actually point my to the "spirit of COOKED", you
know, the philosophy that isn't written down ;)
I also notice that 3195 contains detailled instruction of how to modify
a non-wellformed message when it is being converted for being relayed by
COOKED. But it does contain no instructions what to do if that message
is received via COOKED and needs to be relayed via 3164 or 3195/RAW.
Maybe this is something for the next revision.
Thanks,
Rainer
