I agree with Tom - but also the current draft can acomplish what Alex asked for. If you look at the "origin" SD-ID, the "enterpriseID", "software" and "swVersion" parameters allow this versioning. Obviously, it does not immediately modify the message ID so if you want to use it in processing an event, you must filter on the "origin" and MSGID. But this is the basic mechanism and everything else, I, too, think, is beyond the scope of the current draft. Maybe at some later time, there will be standardization efforts on the contents, but I guess this will be a very tough job...
Rainer > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Tom Petch > Sent: Monday, June 06, 2005 12:14 PM > To: Alexander Clemm (alex); syslog > Subject: Re: [Syslog-sec] Syslog message versioning > > 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: <[email protected]> > 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 > [email protected] > http://www.employees.org/mailman/listinfo/syslog-sec > > _______________________________________________ > Syslog-sec mailing list > [email protected] > http://www.employees.org/mailman/listinfo/syslog-sec > _______________________________________________ Syslog-sec mailing list [email protected] http://www.employees.org/mailman/listinfo/syslog-sec
