Hi all, Based on discussions I had outside of this WG, I would like to ask for the possibility to specify a kind of "simple reliable syslog protocol". RFC3195 is definitely well done work. However, I see some serious issues with it:
- (Un)availibility of BEEP As it looks, BEEP has limited availability to say the least. I have posted a question on the BEEPwg mailing list last week asking for library implementations. I got no response at all (except for Marshal Rose who requested that new libraries should be registered at beepcore.org). So as it looks, BEEP is limited to BEEPcore (which has some serious issues right now) and Roadrunner (which is hard to use without redisigning your whole application [and also hard to use for closed-source projects]). - Complexity of BEEP I wonder if we will ever see an implementation of BEEP (and thus RFC3195) in routers and especially low-end devices like printers and small vendor's routers. - Need to redesign your application If I got it correctly, there is strong need to redisign an application in order to use it with BEEP. Honestly, we do not want to redisign our full product line just to add support for one additional protocol. I have followed the relevant lists and so far have the impression that most implementors stay away from RFC3195 for one or more of the above reasons. So in (current) reality, we are back to the usage of "traditional" (maybe not even RFC3164) syslog if we would like to receive messages from a heterogeneous set of sources. The good point is that we have a widely accepted protocol and it performs relatively good most of the time. But there are weaknesses. Most stem from UDP usage. I hope that it is possible to specify a protocol that fills the gap between RFC3164 and RFC3195. A *simple* syslog reliable protocol, that provides: - reliable transport via TCP - a much larger allowed message size than 1024 characters - support for non-western characters - some more meta data (like the full-blown timestamp, but this might go into the content area and as such might be outside the charter of this WG. I am still mentioning it so at least some header changes can be considered) - maybe hooks for optional encryption and authenticy - but this might go too far - most importantly is easy to implement and does rely on right now readily available libraries, which unfortunately means sockets, only... I wonder if this WG would be willing to step forward into that direction. I am sure such a protocol would not the least be as elegant and advanced as RFC3195, but I think this is it's key advantage: being simple, we would be able to get more implementors to actually implement it. So we wouldn't achieve the 100% that RFC3195 brings, but maybe the important 50% of it. Well, and that looks much more than we currently have... Keep in mind: my key point is that improovement is needed *now* (which means quickly), so I am looking for a solution for the next few years. Maybe this would even be an interim-solution until BEEP becomes actually available... Any feedback is highly appreciated, Rainer Gerhards Adiscon
