Re: sasl in beep or payload

> I agree with Keith and since no-one else seems to be arguing for
> sticking with the sasl-in-beep approach, I'll push those up to
> the payload in the next version.
>
> Just to be clear - this doesn't at all address the http/beep issue.

err, wrong answer...

if you want to put sasl exchanges in the sacred pdus, that's fine. you just
can't use those pdus with beep because it's not how beep works.

the beep spec is very clear that there are two kinds of profiles: tuning and
exchange. tuning profiles do things like sasl and tls. they affect the
global state of the session because they deal with authentication and
privacy, both of which are per-session, not per-channel.

of course, it's perfectly fine to define a set of sacred pdus that don't do
sasl, and then to define a superset that includes some extra pdus that do
sasl. that way you can say that the sacred beep profile includes only the
core set.

however, the fundamental issue is whether we do multiple transports or one.

if the answer is one, which i think it has to be, then the issue is moot. if
the working group picks beep, then you don't need the extra pdus. if the
working group picks http, then you don't need a core set and a superset.

so, we again return to the "the http/beep issue". you can't make it go away
in the fashion you suggest.

/mtr