I don't recall seeing it but I think that this is feature creep we should avoid. Primarily this is a protocol for the transport of event messages, not a standard for the contents of event messages, although we go some way down that road (well far enough for me). If the generators of messages reuse a message id for some different purpose, or create a new message id for the same semantics as an existing message id, on their head be it. They know, or should know, that messages are parsed, are used as triggers in automation and that, as the I-D says,
Messages with the same MSGID should reflect events of the same semantics Any more than that can always go into structured data. Tom Petch ----- Original Message ----- From: "Alexander Clemm (alex)" <[EMAIL PROTECTED]> To: <syslog-sec@employees.org> Sent: Thursday, June 02, 2005 7:53 PM Subject: [Syslog-sec] Syslog message versioning Hi, a quick question: Has versioning of syslog messages been discussed before? I am referring to the message identifier, as identified in the msg-id field. Sometimes it may happen that the same message may be slightly modified from a release to the next - the message text may be updated, but the semantics of the message still remain fundamentally the same - actually, in practice this scenario is not unusual, and can lead to issues. Without versioning of message identifiers, there are in essence two possibilities: The same msg-id is used with a different text. This makes the parsing of the messages harder. Or, a different msg-id is used. This makes parsing easier but adapting of application logic harder - for example, rules that fire on one msg-id have to be updated to reflect the new msg-id, as they should in essence be treated the same. Clearly, vendors can introduce some convention in their use of msg-ids to indicate versioning if they so desire. However, I think it is worthwhile a consideration whether such a convention should be incorporated into the protocol itself, as the ability to version things generally serves to make them more robust. A convention could consist, for example, to suffix subsequent versions of a message with a ".x", x being the message version. Applications will then know that the semantics of the message is characterized by the first part of the message (without the suffix), and will know that the format of the message itself is uniquely identified by the message with the context given by the version. If this was discussed at length before and consciously not included there is no need to reopen this; but if not I'd think this would be simple yet useful feature to consider - my 2 cents. Comments? Kind regards --- Alex _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec
