Re: SACRED Protocol (long!)

> With the current draft, it was not clear how to do this, and hence if
> someone would have liked to implement SACRED on top of http, they
> would more or less had been forced to start all over again (since the
> current proposal relied on BEEP's support of SASL, and http does not
> have this support (yet)).

i think the problem is the "if someone wanted to implement sacred on http"
part...

the reason that people use beep is because it allows them to focus on the
90% of the problem that's "interesting" rather than the 10% of the problem
that's administrative. otherwise, 90% of the effort gets spent dealing with
the administrative part.

if you can get a tight match between http's service and your application's
requirements, then you should use http. the problem comes up when the match
isn't tight enough.

in this particular case, the ietf/iesg is pretty clear that application
protocols be thoughtful with respect to security issues, and that the use of
sasl is a good first step.


> My suggestion is to define a mapping to SOAP. Since SOAP already maps
> to BEEP (as I understand it) and also has a http binding this would
> seem to take care of our immediate requirements.

the problem, of course, is what happens if you don't run soap over beep. in
that case, you're back to square one, because the iesg will require that you
flesh out all the security stuff you'll need to implement sacred in that
environment.

if it positively, absolutely is a requirement that sacred run directly over
http, then time would be far better spent dealing with the security issues
of that mapping. you won't need beep, because it's not saving you any time.
instead, you get to spend 90% of your time working on the administrative
overhead instead of focusing on the problem domain. enjoy!

/mtr