[ next to last message, speaking as the beep guy ...]
I think the issue is that while BEEP can be made to fit our needs, as
can many other things, it seems slightly contorted, and it might well
be easier to define exactly what we need. That's where the discussion
is, thus far. I'd be interested in hearing opinions about "I could
build OCP on BEEP in X weeks". That was a problem with ICAP - it could
almost be built cleanly on HTTP with little work, but that then little by
little it drifted away.
this probably won't come as a surprise to anyone, but speed and
innovation aren't exactly hallmarks of this working group.
when you find yourself in a situation like that, the absolute worst
thing you can do is go off and reinvent a lot of old stuff.
if beep doesn't work, don't use beep. if the answer is "we'll define
exactly what we need", then:
YOU HAVE ASKED THE WRONG QUESTION BECAUSE YOU WILL NEVER FINISH
where i interested in seeing this work complete, i would be leveraging
every existing open standards thing i could get my hands on. i wouldn't
care at all about optimality. i would care about getting the job
done before the IESG wises up and figures out that this working group
isn't going to succeed.
if i could figure out a way to make this thing work sensibly with
telnet, i'd do it.
but, hey, that's just me.
I don't see that BEEP provides any particular help for security.
you're right: beep doesn't make things more secure. what it does is
integrate tls/sasl into a framing/command mechanism, so working groups
that have better things to do (and know they have better things to do)
can work on better things to do.
I think that we definitely need to be XML-free in the sense of being
able to write the header parsing code using a few simple, efficient C
routines. It's OK if a full-weight XML parser can also do the job -
this isn't angle bracket phobia, just a desire to spend more CPU time on
actual OPES services than on header parsing.
XML is not the problem here.
/mtr