2002-12-17-17:25:20 Tom Perrine: > The BEEP protocol looks like it has all the right features (and then > some!).
Yes indeedy "and then some". Multiplexed streams of MIME-structure-framed XML seems a bit over the top, no? > But as Marshall pointed out, the syslog over BEEP doesn't need all > the flexibility and power of every single BEEP feature. If a very simple-to-implement, simple-to-analyze subset of BEEP features suffices for this syslog application, this syslog application should be defined in terms of that subset; else somone will field a syslog implementation against a generic BEEP library (assuming they can find one they can work with), and it'll require features not implemented in the subset. > Once you start adding authentication, integrity and security features, > you're going to end up with something just as complicated as BEEP, as > far as I can tell. _THAT_ is what really makes me object to BEEP in this application. Rather than using an existing, widely-deployed generic transport wrapping for adding authentication, integrity, and privacy (i.e. SSL), we're using a new one with far far less application base. Let's get reliability by just shoving our syslog data over TCP, and where people want authentication, integrity, and privacy, let 'em carry it over SSL. > And if I don't get at least client authentication, integrity and > privacy features, why go to a new syslog protocol? For the reliability of TCP, to lose line-length limits, and to get unambiguous and meaningful timestamps? Would that not be enough reason? If you want in addition client auth, integrity, and privacy, carry your syslog-over-tcp through SSL, of which there are many, many implementations, including hardware-assisted ones, and which has undergone much analysis. Please let's not invent new crypto protocols if we don't have to, that's one of the most error-prone areas of engineering. -Bennett
