comments inline... And an important question for the WG close to the end of the message!
Rainer > -----Original Message----- > From: Darren Reed [mailto:[EMAIL PROTECTED] > Sent: Wednesday, November 23, 2005 6:06 AM > To: Rainer Gerhards > Cc: Darren Reed; [EMAIL PROTECTED] > Subject: Re: [Syslog] New direction and proposed charter > > > > > WG, > > > > <PRI>VERSION TIMESTAMP HOSTNAME APP-NAME PROCID [SD-ID]s MSG > > > > > > I would put the SD-IDs after the message. > > > > This raises the question of what terminates the MSG part ;) > > Using the above syntax, how do you distinguish between [] at the start > of the message from actualy SD-ID data? I used the "short" syntax Chris used in his proposal. The full ABNF would be: <PRI>VERSION SP TIMESTAMP SP HOSTNAME SP APP-NAME SP PROCID SP [SD-ID]s SP MSG This follows the IETF-tradition of SP-delemiting header fields. The SD-IDs are clearly parsable based on that SP. -protcol-15 has the details (everything from there would still apply). > > I think what's missing from the above, is a ':' and the syntax should > be: > > <PRI>VERSION TIMESTAMP HOSTNAME APP-NAME PROCID [SD-ID]: MSG > > The protocol document needs to outlaw ':' being in any field before > the MSG. > > If you mark "VERSION", "PROCID" and "SD-ID" data as all being optional > then the format comes back to being very close to what's in use today. PROCID and SD-ID are optional (but need to have "-" if non-present. Version, IMHO, should NOT be optional because this will be a live-safer when we do the next iteration of the protocol in the future. It also shouldn't be a big deal to stick a "1" character in that position... > > > That would > > mean we would need to introduce byte-counting, at least I think so. > > Well, without the ':' to say where the MSG starts, I'd have argued > "How do you tell where SD-ID ends and MSG starts?" vs there just being > a string of bad SD-ID data following some good SD-ID data. If we have bad SD-ID data, than we have a bad message. I do not think that it is appropriate to try to process bad data - there has been too many security vulnerabilities because of this in recent days... > > As for "but the SD has important information and the MSD does not", > that's simply a matter of how you structure the message. I agree on that. Trunction is always bad.. > > > > > - replace NUL with an escape sequence upon reception (e.g. <00>) > > > > > > Why not \0 ? > > > > That's another good choice. > > It's also how data gets escaped, in general, in Internet stuff. > > > That was my main message. Is it better to live > > with that or introduce a CLR on not allowing NUL? > > I'd like to see NUL outlawed from messages. That would indeed solve a number of issues. The last time we discussed this, it was consensus that this would be a CLR ("crappy little rule") that we wanted to avoid. In the sense of the current discussion: do we still think this is true? Question to WG: should we outlaw NUL from MSG? Rainer _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog