Hi all, many thanks for all the great comments. Let me try to wrap up the concensus I see:
- the proposed format (with brackets and structured data elements) is acceptable - -protocol should REQUIRE senders to emit a specific format - a version is good to have and will also solve compatibility issues (current & future) - adding the enterprise ID can further facilitate message parsing - having the version identifier early in the message is a plus - -protocol should leverage existing syslog momentum, thus UDP transport should use destination port 514 and previous discussion already had the consent that -protocol is sufficiently different from RFC3164 that messages will not be seen as validly formatted by an old-style syslogd. This just as a reminder. As such, I am about to change the initial message header from just <PRI> to [VERSION enterpriseID FACILITY SEVERITY] (separated by SP) so you can recognise new format by the presence of a "[" instead of a "<" in the first byte (plus, you MUST check that the rest of the header is syntaxtically correct in order to avoid misinterpreting a malformed old-style message). So I am NOT going to propose a structured data element for this information. It goes straight into the REQUIRED header. When you think about a new-format message being received by a RFC3164 syslogd, this is probably the best way to handle it, too. Because a RFC3164 syslogd sees this as a message without header, it will not try to parse the rest of the message, which I think is the best that can be done under the circumstances. A sufficiently smart new syslogd may even be able to re-extract the -protocol message from a message that was handled by 3164 syslogds in the middle of a relay chain. So I think this discussion has brought us much value. At least I am very happy with the outcome. I will begin to change the draft in this spirit. I will try to finish it by tomorrow - let's see how much is actually involved. If someone objects my conclusions, I would appreciate if you could do this as quickly as possible - not only to save me some time for the edit, but also in the hope to do things quickly before the meeting ;) Thanks, Rainer > -----Original Message----- > From: Andrew Ross [mailto:[EMAIL PROTECTED] > Sent: Tuesday, January 27, 2004 11:20 AM > To: Rainer Gerhards; [EMAIL PROTECTED] > Subject: RE: syslog-protocol-01 posted & comments > > > Rainer, > > We do need some way to positively identify the -protocol messages as > being different to the old format messages. > > Either of the ways you have suggested would work. > > Anyone favour one method more than the other? > > Regards > > Andrew > > > > > Rainer wrote... > > I think there is indeed a *big* issue. I may be totally missing the > obvious, but how can a syslogd - IN A STANDARD WAY - differntiate > between legacy syslog and -protocol? Its an honest question. > > Hoewever, the only answers I have seen to similar issues so > far is "look > at the headers and guess" - I think this is not good. Maybe we should > REQUIRE a specifc structured data element to be present, to say "hey, > this is new format" - this could solve it. Is that an idea? > > A sample for a REQUIRED structured data element: > > [EMAIL PROTECTED] version="1"] > > Everything that does not have this structued data element, MUST be > considered "old style", everthing that has it MUST be fully compliant > with -protocol. A syslogd just implementing -protocol is free to drop > all packets that do not have this element. > > How does this sound? > > Another approach may be to change the message format, eg. instead of > > <PRI>...... > > -protcol may start with > > [VERSION, FACILITY, SEVERITY].... > > deliberately breaking compatibility. > > Comments are highly appreciated. > > Rainer > > > > > >
