Darren, sorry, but this one calls for a very blunt and direct answer... All others, this is flamish, but I can no longer stand it. Enough is enough. Complaints and flames please to me personally.
Rainer > -----Original Message----- > From: Darren Reed [mailto:[EMAIL PROTECTED] > Sent: Wednesday, November 30, 2005 4:48 PM > To: Rainer Gerhards > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: [Syslog] #3 NUL octets, #4 binary data, #8 octet-counting > > > Andrew, > > > > > Also, if we are to transport syslog over TCP at some stage, > > > we need to keep > > > a delimiter character free from use in the message. Again, a > > > LF would be a > > > good choice for this delimiter. > > > > Here, I disagree. I think we can not set aside a character > for this. If > > we go for TCP, let's do octet-couting. Its reliable, efficient and > > proven. Anyhow, we are not yet doing a TCP mapping, so I > suggest we save > > this discussion until later. > > Why not use LF? Because we - the WG!!!! - have said we want to have the full character set available in the message. Search the archive. Read the drafts. I am tired of doing (re)search for you. I have better things to do than to support your lazyness. The past days, you've brought up a lot of arguments, declined proper queries on your own research (which seems to be non-existing, by the way), thrown in vaporware and shown that you do not know the contents of the drafts. Can you tell me a single reason why I should take your seriously? Ignorance is not a good replacement for evidence. > It will work. There are syslogd implementations about that use LF as > a record delimeter. In other emails you're saying "we must support > binary because some people are going to use this". Now we've > got people > that support LF as a record delimeter already but you don't want to > take this into account. If we change that, we need to change the whole idea. Tell me a single implementation that relies on LF as terminator. On UDP. I know it is done in TCP, but that's a different story, because there it is not part of the message but part of the framing (I guess you understand the difference?). TCP needs to be redefined in any way. So, once again, would you please come up at least once with evidence for your claims? > > Why does what one vendor is going to do mean more than what other > vendors are already doing ? Is there bias here somewhere ? Do you > have any particular preference based on work you've done or through > some sort of affiliation ? My preference is to finish *this* work. It doesn't help to restart this discussion. May I provide a quote from Marshall T. Rose in a similar situation in this WG: ### to carry your argument to its logical conclusion, no working group would ever actually produce any final document, because someone would always be free to introduce additional requirements for a just and noble cause. the ietf is about engineering, not perfection. engineering is about bounding a problem, looking at the tradeoffs, and coming up with a solution. the ietf is about fairness, not perfection. fairness is about providing an process that has transparency and closure. the time to raise these issues was when the group was developing the charter and negotiating it with the iesg... /mtr ### (see http://www.syslog.cc/ietf/autoarc/msg00336.html, Jan, 6 2001) Rergarding my affiliation and past experience: I have actually *implemented* EVERYTHING that currently exists in syslog. Even RFC 3195. Both on Windows and Linux. How about you and your experience and affiliation? [you even quote code without knowing how the iov[] is handled later on in F_FORW... poor guy...] > If you want to discount use of LF as a record delimeter then there > is no reason we must support use of binary because what vendors are > doing is obviously irrelevant. > > Darren > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
