Is CAP really BEEP-only?

Hi Folks,

It seems that CAP requires that one use BEEP as the underlying transport
layer. Is this truely the case? I've read the spec and searched through the
archives, but it seems to be so.

I understand BEEP's usefullness for things like security and compression,
and I have read that it improves asynchronous messaging, but as ubiquity and
interoperability are the key goals of a standard. Would it be possible to
add a soap level integration point for services to interoperate with their
calendar data? Are there significant aspects of CAP that couldn't be
implemented at that level?

What I would like to do is provide a nicer web based client for folks on
different platforms to share their calendar data and schedule meetings. It
seems that since CAP is the current standardization effort that I should try
and adhere to it, but requireing the use of BEEP makes it difficult to see
how I can use a web based client. I can work with BEEP in Java or Python,
but then the users would have a binary install to make and I have to worry
about multiple platforms. I would prefer to use DHTML, Flash or Curl, and
use soap headers to communicate to other CAP clients. (Though Curl and Flash
require an install, their file sizes and installation proceedures are much
more in line with what I think an average user will be willing to follow.)

I know I could create a decent scheduling app using the older formats and my
own messaging solutions, but I'd rather do things right if I can. I
appreciate the requirements and design work this group has done and it's
improved my understanding of what direction to go in in general. I will
understand if small developers like myself are not in the scope of CAP's
target audience, but the sheer number of web based calendar clients suggests
that it might be worth accomodating that part of the developer base with a
soap interoperability layer.

Any thoughts appreciated.

Thanks

Cortlandt Winters