Re: [111attendees] So, what are jabber scribes actually doing, these days?

John C Klensin <> Thu, 29 July 2021 13:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 700643A2235 for <>; Thu, 29 Jul 2021 06:09:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yX_BHckyCa3F for <>; Thu, 29 Jul 2021 06:09:43 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A7A263A1D6F for <>; Thu, 29 Jul 2021 06:09:43 -0700 (PDT)
Received: from [] (helo=PSB) by with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <>) id 1m95nA-000G6z-O7; Thu, 29 Jul 2021 09:09:40 -0400
Date: Thu, 29 Jul 2021 09:09:34 -0400
From: John C Klensin <>
To: Spencer Dawkins at IETF <>, Sean Turner <>
Message-ID: <5A346DF0A2B69EB397207C72@PSB>
In-Reply-To: <>
References: <> < om> <> <> <>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Scanned: No (on; SAEximRunCond expanded to false
Archived-At: <>
Subject: Re: [111attendees] So, what are jabber scribes actually doing, these days?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Mailing list for IETF 111 attendees <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 29 Jul 2021 13:09:47 -0000

--On Wednesday, July 28, 2021 12:12 -0500 Spencer Dawkins at
IETF <> wrote:

> What I thought, was that chairs needed to be looking at the
> mic queue. which by default is toggled with the chat window,
> and might not have the screen real estate to detach the chat
> in Meetecho, so you can move it to another part of your screen
> (or another Display), or might not know you can detach the
> chat window at all. If the chairs can see both (especially if
> the meeting has more than one chair), ISTM that the chairs
> would know about questions from jabber at the same time as
> everyone else.

In addition to chair bandwidth, screen real estate, etc., there
is a more fundamental problem: with the current Meetecho setup,
it has impossible (or, at least non-obvious) to have both the
chat and participant frames open at the same time.    Without
the latter open, and a good deal of screen real estate and
attention to scrolling, it is not possible to see the queue or
figure out who is speaking if the speaker is not transmitting
video.  There are ways to solve the chat visibility part of the
problem.  The speaker recognition problem could be solved by
putting a small "now speaking"  line with a name somewhere near
the top center (or bottom center) of the screen.   And, modulo
those who need to be able to type rather than speak (as you
noted in your follow-up), some of the rest of the problem could
be solved by explaining to Meetecho who the official
Jabber-wstcher is and letting them put others in the queue.

<rant> Most of these suggestions have been made many times
before.  At least my experience had been that back in the days
when Meetecho was a trusted partner, these issues and the
tradeoffs got discussed among knowledgeable people and were
either implemented or, when rejected suggestions came up again,
there were clear explanations of why they were infeasible or bad
ideas.  I can't tell, but it certainly looks like we have
slipped Meetecho into "just a contractor" mode with decisions
being made by someone else, out of the view of those who would
prefer to technical work in the IETF than monitor every
administrative meeting and announcement and who obviously are
not trying to use these tools to get the work of the IETF done.