> At 01:48 PM 12/18/2002 -0800, Darren New wrote:
> >Bennett Todd wrote:
> > > Yes indeedy "and then some". Multiplexed streams of
> > > MIME-structure-framed XML seems a bit over the top, no?
> >
> >Um.... BEEP uses SSL. BEEP includes a mechanism for saying you want to
> >use SSL. (Well, TLS, but you know that.) BEEP does not replace TLS - it
> >merely provides a way for you to ask the other side to use TLS, and for
> >the other side to accept or refuse.
>
> AND it introduces more processing in between your payload and TLS.
uh, not exactly. see below.
> >I'm not sure I understand why you don't already know this, if you've
> >read the syslog-reliable spec.
>
> because in the syslig-reliable spec (RFC 3195) on page 5 it says...
>
> "At the time of this writing, only one such transport is defined, in [4],
> which specifies BEEP over TCP."
>
> Now in fact it specifies BEEP over TLS, I gather.
bzzzt. wrong answer. read 3080 and you'll see that tls sits on top of tcp.
> The point is, BEEP adds a layer of overhead that people are debating the
> value of.
and would you educate as to exactly what that layer is? let's see is it:
- the framing? well, i suppose we could view syslog messages as
self-terminating with the \n?
- the security? well, beep just lets you determine whether it's
available and if you want to make use of it
- the negotiated release? well, that's probably something we don't
need (be sure to mention that to the http folks).
my (admittedly biased) theory is that when you sit down and try to find
exactly what the "layer of overhead" is, you'll find that it's all those
things that you need to do anyway...
/mtr
