Re: SACRED Protocol (long!)

> Actually Marshall, I think it is a good thing to run SACRED on top of
> BEEP. However, I also do believe that it should be possible to run
> SACRED on top of other protocols as well, including protocols that
> does not have BEEP's support for SASL. By integrating SACRED's
> security mechanism into SACRED itself we claim to achieve this.

everything has a cost. by mandating

> > > -allow SACRED protocol exchanges to run on top of any reliable
> > >  transport, including SOAP, http, BEEP, and other protocols,

you have increased the cost of entry for developers (which mappings do i do
first) along with the switching cost for consumers (can't switch to vendor
Y's product, because it doesn't support the mapping used by vendor X's
product).

very often having too many choices is far worse than having once choice.

/mtr

ps: of course, this all assumes that the wg can agree on N mappings in
finite time, that the iesg goes along with it, etc., etc. in other words,
the scope of effort just got a whole lot bigger...