Hi, My co-workers in university also encountered this issue when implementing syslog-tls, and used a mechanism similiar to the one of Rainer to overcome it. As I am aware of, currently there are two syslog framing implementation and both the implementaters considered this boundary condition. So, my perception is careful implementater would have no problem, and a note for reminding is enough.
Regards, Miao > -----Original Message----- > From: Rainer Gerhards [mailto:[EMAIL PROTECTED] > Sent: Wednesday, December 13, 2006 4:34 PM > To: [email protected] > Subject: [Syslog] Framing in syslog-transport-tls > > Miao, WG, > > I have partially implemented syslog-transport-tls in two > different programs (MonitorWare Agent and rsyslog). My focus > was the framing, not tls itself (I needed the new framing for > some other functionality, but that is a separate story). I > would like to share my experience during that implementation. > This is *not* necessarily a request for change. I just though > that might also come up during IETF last call, so I think the > information is useful. > > FRAME-LEN is a variable length field. It specifies the length > of the frame including the length of FRAME-LEN itself. This > is no real problem for the receiver. On the sender side, > however, it is a bit tricky. I need to obtain the length of > the ASCII-encoded field including the (potentially changing) > size of itself. Let's look at a sample. > > We have a message with 996 octets. Now I obtain the > information that I need 4 octets to encode this ("996 "). I > need to add that to the total message length, bringing me up > to 1000 octets. Now, I need to re-check my buffer > requirements. I now learn that I need a 5 octect encoding. > This I need to add to the previous length of the message > (996), resulting in a total frame length of 1001 octets. > > If we would just count the MSG part of the frame, there would > be no such ambiguity, because I would set FRAME-LEN to > whatever size I know the MSG part has. It would be 996 in > this case. However, that would mean we have two different > framing mechanisms inside the frame - octet stuffing (the > SP) after the count and then octet counting for the rest of > the message (I think http uses such a mechanism, but have not > verified). > > On the other hand, I can easily implement the current > specification with few lines of code. Here is a C sample of > the code I actually use in > rsyslog: > > iLenBuf = snprintf(szLenBuf, sizeof(szLenBuf)/sizeof(char), > "%d ", len); iLenBuf = snprintf(szLenBuf, > sizeof(szLenBuf)/sizeof(char), "%d ", len + iLenBuf); > > Where len is the length of SYSLOG-MSG and iLenBuf the total > frame length. For context, see > > http://rsyslog.cvs.sourceforge.net/rsyslog/rsyslog/syslogd.c?r > evision=1. > 159&view=markup > > and scroll down to line 1766. > > Initially, I was of the view that it would be advisable to > think about changing -transport-tls so that the octet count > is just the length of SYSLOG-MSG. After some thinking, I now > believe that it is fine as it currently is specified. I > suggest a sentence "warning to implementors" > to point to the potential mis-implementation. On the other > hand, a receiver must rely on the octet-stuffing in any case. > Because it needs to find the SP in order to find the end of > the octet count. That would be an argument to contain only > the size of SYSLOG-MSG in the counter. > > Given the fact that -transport-tls is already submitted to > the IESG AND there is no real problem with the current > specification, I propose not to change it (except for adding > a warning as outlined above). > > Sorry for the late catch, but these things seem to only > appear when you actually implement... > > I would appreciate comments on the issue. > > 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
