> My 2 cents... Do the byte counting. Look at the headers of > pretty much any successful protocol (TCP, IP, UDP, etc) - > they all specify length of payload. Special character > sequence is really a hack IMO!
After some thinking, I agree with Anton. I, too, think that octet-counting is superior, as it leaves the door open for changes in the upper layer. So I now strongly vote for using this approach. > Just to be clear, there was never any intention to allow > multiple messages per UDP datagram. So, this discussion > probably does not apply to the UDP transport mapping. I agree on this point with Anton. We should not add any additional overhead to the UDP transport. There is few reasoning for multi-chunk messages in a potentially 448-octet constraint message. There may be some valid use cases with ultra-compact messenging, but that should probably done in another transport and/or optionally in a revision once we got some experience with actual implementations. Rainer > Thanks, > Anton. > > > -----Original Message----- > > From: Chris Lonvick (clonvick) > > Sent: Wednesday, March 15, 2006 5:26 PM > > To: Rainer Gerhards > > Cc: [EMAIL PROTECTED] > > Subject: Framing in syslog messages - RE: [Syslog] > > Preliminarysyslog-transport-tls document - issue 3 > > > > Hi, > > > > This is an issue that we need to discuss. I've had some > > discussions with various people on this subject who's > > opinions I trust. They also suggest that we do have 2 > > options as Rainer states. Let me describe this in a bit > more detail: > > > > The consensus from all is that syslog-protocol should not > > explain how to have multiple syslog messages in each packet. > > That should be done in each of the transport documents so > > that transport mechanisms can frame the messages. This > > ensures a good fit if syslog is placed into a new transport > > that already has a framing mechanism. This is how it has > > been done in RFC 3195. > > > > As Rainer says, we can reserve a character or characters to > > separate messages. We could use ASCII characters such as > > CRLF or we could use a > > UTF8 character. See: > > http://www.unicode.org/faq/utf_bom.html and > > http://www.unicode.org/reports/tr14/index.html > > This would require that we place a very strong message in the > > Security Considerations section of each transport document > > that would warn against an inappropriate use of the separator > > character(s). For example, if CRLF is chosen as the > > separator, the receiver may get a message with a CRLF in it > > that does not signify a separation of messages. This will > > probably go away with time as more poeple adopt to the standard. > > > > Alternatively, we could count bytes to show the end of a > > message. The receiver would count to that point and decide > > if there is another message after that. Having this option > > would not require any additional messages in the Security > > Considerations section as there would be no doubt about the > > end of a message. > > > > I want to open this discussion to the group. If we can agree > > to some mechanism then we'll get Anton, Fuyou and Yuzhi to > > put this into their IDs. > > > > I will say that the WG is not addressing the transport of > > binary messages at this time. However, I know that it's a > > concern of this group and I would hope that the people who > > think about this take that thought into consideration when > > they send in their comments. > > > > Thanks, > > Chris > > > > > > On Wed, 15 Mar 2006, Rainer Gerhards wrote: > > > > > Miao, > > > > > > thanks for the great (and quick) work. I can not review it > > fully right > > > now, but I have seen one issue that I would like to comment > > > immediately on. More comments follow later. > > > > > >> [Issue 3] The problem of CR LF is it can not process > binary data > > >> well. How to process Syslog signature/certificate message? > > > > > > With the current status of syslog-protocol, you can NOT do > > > octet-stuffing. The reason is that any character is valid > > inside MSG > > > and this includes the CR LF sequence. > > > > > > So we have two options: > > > > > > 1. change -protocol to disallow CR LF > > > 2. use byte-counting for framing in -tls > > > > > > Option 1 has been discussed in the past and mostly been rejected. > > > However, this is the first time that we have a real > standardization > > > use case for excluding it. Currently existing (non-standard) > > > syslog/TCP uses CR LF (or lone LF) as record delimiter. So > > it might be > > > useful to take that route. > > > > > > Option 2 has the advantage of greater aplicability plus > enables the > > > application developer to use more efficient buffering (as > > the needed > > > buffer space is known in advance). > > > > > > I have no strong opinion which option is better, but I tend > > a little > > > bit to option 2. > > > > > > Rainer > > > > > > _______________________________________________ > > > Syslog mailing list > > > Syslog@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/syslog > > > > > > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > > > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
