Re: BEEP/SOAP (Was RE: SACRED Protocol (long!))

[Magnus Nystrom <magnus@xxxxxxxxxxxxxxx>]

Hi Stephen,

(Chipping in though the posting was directed to Marshall and Mike)

I think that BEEP has some nice characteristics that would make a
SACRED-on-top-of-BEEP architecture worthwhile. In particular, since
there is a BEEP profile for SOAP in the works, it seems as if the
people doing that profile felt that the binding was useful. As I
stated earlier, if we map SACRED to SOAP we will get these benefits
too, but with the added advantage of leveraging other SOAP bindings.

And, as I mentioned in an earlier posting, the task of doing the
mapping should not in itself require that much work, c.f. XKMS which
currently maps to SOAP in Appendix A.

-- Magnus

On Fri, 7 Dec 2001, Stephen Farrell wrote:

> Marshall, Mike,
>
> (Just trying to eliminate or make specific one degree-of-freedom...)
>
> In your opinion is there any point in sacred including sasl
> elements in its payload, but still using beep as transport?
>
> That is, this thread has mentioned the following options:
>
> "sacred = payload + beep(sasl)"                [the current I-D]
> "sacred = payload(sasl) + soap"                [mike's question]
>
> does:
>
> "sacred = payload(sasl) + beep" make sense or not? (To be clear:
> this means using beep as transport, and not leveraging the sasl
> support available in beep, but rather sending the sasl PDUs in
> the sacred payload.)
>
> If it did make sense, then one could imagine a way 'round this
> where we split into two drafts, one for payload(sasl) and one
> (or more) for "sacred = draft1 + transport". However, I'm
> not conviced that "sacred = payload(sasl) + beep" does
> make that much sense, nor that we've sufficient bandwidth
> and interest to progress multiple documents.