[Standards] Fwd: Radical Solution for remote participants

Peter Saint-Andre stpeter at stpeter.im
Mon Aug 19 22:15:31 UTC 2013


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* <doug.mtview at gmail.com <mailto:doug.mtview at gmail.com>>
> Date: Tue, Aug 13, 2013 at 2:00 AM
> Subject: Radical Solution for remote participants
> To: John Leslie <john at jlc.net <mailto:john at jlc.net>>
> Cc: IETF Discussion Mailing List <ietf at ietf.org <mailto:ietf at ietf.org>>
> 
> 
> 
> On Aug 12, 2013, at 1:06 PM, John Leslie <john at jlc.net
> <mailto:john at jlc.net>> wrote:
> 
>> Janet P Gunn <jgunn6 at csc.com <mailto:jgunn6 at csc.com>> 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
> 



More information about the Standards mailing list