On Wed, Dec 13, 2006 at 09:33:38AM +0100, Rainer Gerhards wrote:
> 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.
[...]
> 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).
[...]
> 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.
Unfortunately, I did not catch this when I reviewed this document. I
believe not including the framing characters in the length value makes
a lot of sense; in fact, FRAME-LEN should perhaps have been MSG-LEN to
start with. Taking any process issues aside, I would be in favor of
such a change.
/js
--
Juergen Schoenwaelder {International|Jacobs} University Bremen
<http://www.eecs.iu-bremen.de/> P.O. Box 750 561, 28725 Bremen, Germany
_______________________________________________
Syslog mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/syslog
