Again, since I'm taking my own notes ... --------- Discussion heated back up with a discussion of the relationship between the XCON Framework and the SIPPING Conferencing Framework. Keith D. opened the discussion with a suggestion that discussion of the notification service be removed from the former. Several parties objected on the grounds that (a) if a notification service was central to XCON-enabled conferencing systems, then (b) it needed to be addressed (at least at a high level) in the XCON Framework. More generally, the majority of people speaking up seem to favor Keith L.'s and others' view that the XCON Framework document should provide readers with a coherent, high level view of the perspective XCON is taking on conferencing and which pieces thereof XCON is developing (or not). Put another way, one should not have to read the SIPPING Conferencing Framework as well in order to get such a high level view. With that in mind, the XCON Framework authors will be adding a variety of material BACK to the draft, while simultaneously working with SIPPING to minimize the redundancy between the two documents. Next, Henning presented his perspective on a variety of topics (cf. http://ee.wustl.edu/~alan/xcon/XCON-interim-henning.ppt). His presentation included intriguing suggestions re "active" vs. "latent" conferences and "conference trees", in particular. There was some skepticism as to the utility of using more than 3-level trees -- in which case the hierarchy reduces to that in the current conference framework (with the possible exception of the way it accommodate sidebars) -- but no strong resistance. The discussion of latent meetings also prompted Keith L. to remind everyone of something Cullen said recently: It is useful to be able to retain information about a conference even after it is over -- e.g. in order to access a recording. Henning added to this the example of being able to clone an old meeting. Specific functionality to address this requirement may be out of scope, but can be "flagged" by saying that conference state is retained for some (implementation-specific) time after the conference ends. Next up: A discussion of CCCP, led by Orit. Didn't capture much of this. Refer to the slides. Henning doesn't like the options presented, however; his nascent counter-proposal can be found in the slides referenced above. In particular, he wants to - avoid protocols that require (atomic) transaction semantics, - avoid re-inventing SOAP or another RPC protocol, - re-use existing security mechanisms He proposed SOAP, XML-RPC or IMAP/POP (SASL) instead. In response ... Alan: Conference control isn't rocket science. This is overkill. We're not going to do SOAP or XML-RPC. No way. Eric: Why not? We're already most of the way there. The increment isn't going to kill me. Keith D.: You don't want transaction semantics, but the options you've presented have transaction semantics. [Ed.: Doesn't sound right.] Orit: Transactions are FUNDAMENTAL to conferencing systems. It must be possible for a client to execute a number of control "primitives" without interleaving them with requests from other clients. (Compelling examples would be nice here.) Keith D.: So what's wrong with XPATH over SOAP? It can do everything you're talking about, albeit at the syntactic level. Brian & Henning: If we did that (or anything else at the syntactic level), we would have no chance of having "old" clients adapt to "new" controls. No resolution.