Re: [vmeet] Supporting interim meetings (was Re: Duties of WG Chairs)

[Dave Cridland <[e-mail]>]

I've been asking around for solutions to these issues which are based  
around open standards. While I fully understand, and indeed support,  
the need for an "out of the box" solution to this, I'd like an "out  
of the box" solution that used a suite of open standards to achieve  
these goals.

I'm speaking here both as an individual fairly heavily involved with  
open standards work, and also as someone who ends up participating  
remotely at the majority of IETFs, and has participated remotely at  
multiple Interim meetings as well. I don't claim exhaustive  
experience, mind. :-)

On Tue May 12 01:01:00 2009, Dave CROCKER wrote:
> 1.  Meeting management -
> 
>     a)  Ability to queue up participants, as if at a microphone
> 
>         For meetings of a group that can easily be 20-40 people,  
> with relatively little history of group collaboration, the job of  
> meeting management is vastly easier when there is some functional  
> help for coordinating who wants to speak next.
> 
> 
>     b)  Ability to shift who is presenting
> 
>         This is the equivalent of having different folk come up to  
> the front of the room and plug in their laptop.  I suspect that a  
> failure to support this mode of participation would seriously  
> hamper the convenience -- and possibly effectiveness -- of meetings.
> 
> 
This is, it appears, provided by the XCON working group, and in  
particular by RFC 4582, which it appears is supported by at least  
some people. I apologise for being quite so vague, but SIP isn't my  
field at all (I have some SIP/VOIP contacts via the XSF's work on  
Jingle, and I'm merely relaying).

That said, I'd note that no interim or "design team conference call"  
I've ever participated in has had anything like this, and they've  
worked fine.



> 2.  VOIP for voice
> 
>     As noted above, a telephone bridge does not have to be a  
> requirement, for meetings that are infrequent.
> 
> 
Presumably, we need to be considering SIP or Jingle (XMPP VOIP) here.  
SIP has the conferencing implementations, whereas this isn't really  
defined for Jingle. (A shame, since Jingle would integrate neatly  
with the XEP-0045 chat rooms we're already using with much success).

Of course, some SIP implementations also talk Jingle and/or H.323,  
hence opening the client field a bit.

> 3.  Shared slide presentation
> 
>     Shipping powerpoint files around is tolerable only for special  
> cases, I believe.  Since we are talking about broad-based, regular  
> use, we should make presenting slides as comfortable as it is in a  
> room.  A major benefit of integrated slide presentation and control  
> is that there is then no need to worry about people's knowing what  
> slide is showing.
> 
> 
I agree this is nicer than the usual flurry of "what slide are we  
on?" in the MUC room, but in general, the current practise of putting  
slides on a known website, and calling out slide numbers, works well  
enough for me to not care much if this is missing.

> 4.  Shared white board
> 
>     My gut says that this really is an extremely useful feature for  
> many meetings.  And since it's available in a number of products,  
> it seems to make sense that we require it.

My gut says that since I have seen no use of whiteboards, physical or  
virtual, at any IETF related meeting, then while we might use them if  
we had them, they won't be missed if we don't. So I'd argue this is  
"nice-to-have".

> NICE-TO-HAVE
> ------------
> 
> 5.  IM
> 
>     Existing IETF jabber can suffice, IMO.  IM integrated into the  
> conferencing tool would be nice, but only if it is on a par with  
> the jabber service we are used to.
> 
> 
I'm assuming by this you mean that IM (or rather, multiuser chat) is  
indeed a requirement, but it needn't be integrated, and the existing  
XEP-0045 service is adequate.

> 6.  Telephone bridge (in, out)
> 
>     mumble.  This adds quite a bit of expense.  I could argue  
> /against/ supporting it at all(!)

Actually, one of the real benefits of using an open protocol, perhaps  
SIP, for this kind of things is that not only do many implementations  
support telephone bridges, but it's my [limited] understanding that  
local organizations could even provide their own phone bridges  
relatively simply, which spreads, at least, any additional expense.

Dave.
-- 
Dave Cridland - mailto:[e-mail] - xmpp:[e-mail]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade