I thought we were targeting the TLS transport to the new syslog-protocol, not the current informational RFC 3164. There are some considerations in the charter for partial syslog-protocol compatibility with RFC 3164. But I don't think we have called for the new transport to necessarily work with RFC 3164, did we?
Does this need to be a requirement or can the implementations that wish to support both provide features to transition clients from one to another? Thanks, Anton. > -----Original Message----- > From: Nagaraj Varadharajan (nagarajv) > Sent: Friday, August 11, 2006 3:51 PM > To: [EMAIL PROTECTED] > Subject: RE: [Syslog] delineated datagrams > > Sorry for jumping in late on this topic and also pardon me if > I have not understood the discussion correctly. > > My thought is that the easiest way syslog over tls will be > implemented will be by existing apps taking what they have > for syslog over TCP and adding the TLS layer. So in terms of > easy implementation and adoption, it may be good to support > whatever is being done for tcp syslogs now. I believe that LF > as a separator is quite common currently. > However, I do agree that this is a good opportunity to > upgrade to a better method. My only concern is that this > should not force applications to drastically change their > underlying syslog implementations > > Regards, > Nagaraj > > -----Original Message----- > From: Rainer Gerhards [mailto:[EMAIL PROTECTED] > Sent: Thursday, August 10, 2006 9:22 PM > To: Balazs Scheidler > Cc: [EMAIL PROTECTED]; Tom Petch > Subject: RE: [Syslog] delineated datagrams > > > Maybe this already has been said ;) > > > > This makes sense. What about other control characters? > > > > > We need to differentiate between on-the-wire format and > storage format. > On-the-wire, I would escape only LF and the escape character. > In storage, I would escape any control character (which can > be quite tricky with Unicode). Our current scope (and IETF > scope) is on-the-wire. So I propose not to mangle any more > characters than absolutely necessary. > > Rainer > > _______________________________________________ > Syslog mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/syslog > > _______________________________________________ > Syslog mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list [email protected] https://www1.ietf.org/mailman/listinfo/syslog
