Chris, while I think this sounds very tempting, I also think there are some inherent problems with it:
#1 you do not know *where* (more precise: after how many octets) that element is present In extreme cases, it might only be valid after more then 64k #2 it could become truncated Structured data is not guarded against truncation. #3 architectural concerns I do not think it is appropriate for a lower layer to obtain information from an upper-layer field. That would require the lower layer to parse the upper layer field, which it conceptionally should not even be aware of. All in all, I am in strong favour of a dedicated tls-transport only header for the octet count. Rainer > -----Original Message----- > From: Chris Lonvick [mailto:[EMAIL PROTECTED] > Sent: Friday, March 17, 2006 5:38 PM > To: Rainer Gerhards > Cc: Balazs Scheidler; [EMAIL PROTECTED] > Subject: RE: Framing in syslog messages - RE: > [Syslog]Preliminarysyslog-transport-tls document - issue 3 > > Hi, > > Why wouldn't this information be contained in a structured > data element > within each frame? > > Thanks, > Chris > > On Fri, 17 Mar 2006, Rainer Gerhards wrote: > > > Bazsi, > > > >> Agreed, let's go for octet-counting. How would that look like? Two > >> octets before every message? That would limit message size > to 64k, is > >> that sufficient? (I personally say it is, messages larger > >> than 64k would > >> potentially mean that they cannot be held in memory) > > > > there is the good, old size issue resurfacing. I'd say > let's not get on > > that slippery slope again. The compromise so far is - you > can use any > > size as long as the receiver permits it. I'd say we should > stick with > > it. That means we should probably also stick with the > ASCII-only Space > > delimited header. So the transport header would be > something like this > > > > TLS-HEAD = OCTCOUNT SP > > OCTCOUNT = 1* DIGIT > > > > Two practical samples would be > > > > "140 <rest of syslog message" > > > > or > > > > "256000 <rest of syslog message" > > > > The later is an intentionally horrible long message. But again, I'd > > leave this door open. > > If the receiver thinks 256000 octets is too large, it can > read the first > > 64k and drop the rest. > > 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
