I'm waiting for the IETF discussion to yield clear and stable requirements before I start to design any XMPP extensions. :-)
On 8/13/13 1:31 AM, Dave Cridland wrote: > How much of this stuff can we do already? I know that much of (6) has > been implemented in military clients, and I suspect (2) is an > application of Jingle. (7) smells like a BOSH app, or some kind of a bot > with a web UI. > > ---------- Forwarded message ---------- > From: *Douglas Otis* <[email protected] <mailto:[email protected]>> > Date: Tue, Aug 13, 2013 at 2:00 AM > Subject: Radical Solution for remote participants > To: John Leslie <[email protected] <mailto:[email protected]>> > Cc: IETF Discussion Mailing List <[email protected] <mailto:[email protected]>> > > > > On Aug 12, 2013, at 1:06 PM, John Leslie <[email protected] > <mailto:[email protected]>> wrote: > >> Janet P Gunn <[email protected] <mailto:[email protected]>> wrote: >>> >>>> Again, it strengthens the case to get it done right. This part has been >>>> working well though. >>> >>> Not necessarily. There was one WG where I had to send an email to the WG >>> mailing list asking for someone to provide slide numbers on jabber. >> >> ... and Janet was merely the one who _did_ so. Others did their best >> to guess at the slide numbers. >> >> At least one-third of the sessions I listened to failed to provide >> all we are told to expect in the way of jabber support. :^( >> >> OTOH, we _do_ get what we pay for; so I don't mean to complain. > > Dear John, > > You are right about getting your money's worth. In the case of remote > participants, they are charged nothing and receive no credit for having > done so. Often their input is ignored as well. > > A radical solution for meaningful remote participation is to change how > A/V in meeting rooms operate. This change will require a small amount > of additional equipment and slightly different room configurations. > > 1) Ensure exact digital interfaces driving projectors are fully > available remotely. > > 2) Ensure Audio access requires an identified request via XMPP prior to > enabling either a remote or local audio feed. > > 3) RFI tags could facilitate enabling local audio feed instead of an > identified request via XMPP. > > 4) In the event of the local venue loosing Internet access, the device > regulating A/V presentations must be able to operate in a virtual mode > where only remote participants are permitted to continue the meeting > proceedings. > > 5) Important participants should plan for alternative modes of Internet > access to remain part of the proceedings. > > 6) Develop a simple syntax used on XMPP sessions to: > 1) signify a request to speak on X > 2) withdraw a request to speak on X > 3) signify support of Y > 4) signify non-support of Y > 5) signal when a request has been granted or revoked. For local > participants this could be in the form of a red or green light at their > microphone. > > 7) Develop a control panel managed by chairs or their proxies that > consolidate and sequence requests and log support and nonsupport > indications and the granting of requests. > > 8) Chairs should be able to act as proxies for local participants > lacking access to XMPP. > > 9) Chairs should have alternative Internet access independent of that of > the venue's. > > 10) Establish a reasonable fee to facilitate remote participants who > receive credit for their participation equal to that of being local. > > 11) The device regulating A/V presentations must drive both the video > and audio portions of the presentations. A web camera in a room is a > very poor replacement. > > 12) All video information in the form of slides and text must be > available from the Internet prior to the beginning of the meeting. > > Regards, > Douglas Otis >
