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?revision=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 Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog