> beep is designed in such a way that you basically pay for > what you use. if you know before hand that you're going to > have at most two channels open (channel zero for management, > and another channel for data exchange), then you can write > the transport mapping stuff in one screen of C (maybe two > pages if you like comments).
Mmmmhhh... I sometimes like comments ;) But I am still not convinced that the minimal implementation can be done over breakfast... Any known approach for such a minimal lib out there? > (hint: when the peer asks to > start another channel, send back an <error/>). > > in fact, the "just say no" thing works great for most of > beep's features. what you're left with is a mandatory framing > mechanism and some xml parsing for channel 0. Well, I thought this was not the spirit of BEEP - but I guess you must know better ;) I'll re-read the RFC in this regard. Generally speaking, I still feel a little like I will implement SMTP but need to write the TCP part of the IP stack first... The point is that I am interested in syslog and interested in implementing RFC3195. Now when I come to actually try to do it, I see that it relies on another RFC with very limited availability (in running code). Of course, I see the point that if the lib needed can be crafted relatively quickly, it might be worth simply doing that instead of complaining ;) I just wonder nobody did before... > here's an interesting thought experiment: list all the > requirements that the community has for the-next-syslog, e.g., > > > - reliable transport via TCP > > - a much larger allowed message size than 1024 characters > > - support for non-western characters [SNIP for brevity] > sockets, only... > > is a good start (although the liklihood that the security > guys will let you avoid requirements for authenticity, > integrity, and privacy are nil). I know they won't like it - in fact, even I don't like it. But face it: even an "enhanced" RFC3164 implementation that runs over TCP instead of UDP brings much in terms of reliability. We know it, because we have done it. So I don't think the question is if it would be great to omit it, the question is if it can bring value over the current state of implementation. And if it is easy enough to bring implementors to use it... > > anyway, when you compile the final list and then start the > design work, i think it likely that what you have will be at > least as complex, and probably more complex than beep. Fully agree. And this is exactly the reason why I omitted many of those things. I am sure that RFC3195 and syslog-sign properly address (most of) these needs. I am looking for a damn simple, unsophisticated but still-better-than-current-practice thing that will be extremely easy to implement and such *quickly* gets implementations (quickly is the key word here). I am more looking for an enhanced RFC3164 with some added reliability than a stripped-down RFC3195. > why? > because the secret of beep is that it's nothing more than a > tight integration to a number of proven solutions to doing > applications stuff. the integration part is new, the rest of it isn't. > > now, the parts of your requirements that don't deal with > protocol exchanges (e.g., i18n) are interesting, and i think > that may be an interesting thing for the wg to get into, > assuming the ADs are interested in extending the charter, and > depending on your reasoning, they may very well be... In fact, we are doing a lot of business with Japanese security folks and especially the 1024 char limit and the charset hurt *very much* in this space. We had to take the liberty to violate these sections of 3164 to make things work... Rainer
