[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: BEEP/SOAP (Was RE: SACRED Protocol (long!))
(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.
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]
> "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.