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

John C Klensin <> Thu, 29 July 2021 19:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A2A863A16CD; Thu, 29 Jul 2021 12:08:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sE02Y41u20ts; Thu, 29 Jul 2021 12:08:41 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9581B3A16C1; Thu, 29 Jul 2021 12:08:41 -0700 (PDT)
Received: from [] (helo=PSB) by with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <>) id 1m9BOZ-000Had-DT; Thu, 29 Jul 2021 15:08:39 -0400
Date: Thu, 29 Jul 2021 15:08:34 -0400
From: John C Klensin <>
To: Robert Moskowitz <>, Mirja Kuehlewind <>, Spencer Dawkins at IETF <>, Sean Turner <>
Message-ID: <FDC8E6614EC3C3B924B216B6@PSB>
In-Reply-To: <>
References: <> <> <> <> <5A346DF0A2B69EB397207C72@PSB> <> <>
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 19:08:48 -0000

--On Thursday, July 29, 2021 11:43 -0400 Robert Moskowitz
<> wrote:

> On 7/29/21 11:37 AM, Mirja Kuehlewind wrote:
>>> 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.

>> You can detach the chat window into a separate window.

Tried doing that.  Discovered that it helps with some issues and
not others, but those problems are more unique to me than
general issues. 

> And with 2 screen approach move it to your expanded real
> estate.

Of course.  But I am trying to stay focused on general issues
that I believe cause problems for many people (see Carsten's
recent note and my response) rather than on my special problems,
why I have those problems, the options I do and do not have (or
might be able to have) in my setup, and what might or might not
be effective in mitigating the specific issues I am having.

However, since you both brought up variations on that option and
because others might have similar issues, let me try to
generalize a bit (people who don't like my long messages should
stop reading here or skip to the last paragraph):

(1) If one were using a single, relatively small screen (size
measured in cm, inches, or relative to the visual perception
capabilities of the user), then detaching the chat window or
using a separate client is problematic because, if the other
information on the Meetecho screen is important, there is no
place to put the chat material without losing information.  The
same comment would apply if one had a large display or even two
or three of them but needed to extend the Meetecho window across
all of them in order to be able to see properly.

(2) Even if it is possible to get the chat frame out of the way,
having to scroll up and down in the participant frame in order
to tell who is speaking (if that person is not sending video),
who is in the queue and how long it is, etc., is problematic.
The worst part of that problem is the "who is speaking"
information, which could easily be displayed in the unused area
near the top of the Meetecho window or, perhaps better, to the
right where the speaker's image would appear if they were
sending video.  

(3) FWIW, the new "private conversation" facility in Meetecho
has become part of the problem: the relevant frame appears in
the lower right of the Meetecho window, uses small type, and, at
least AFAICT, cannot be moved or expanded.

(4) For more years than I can remember (but going back to when
we were still using overhead projectors), there have been
regular incidents of people using too-small type and trying to
squeeze too much information onto a page. I think that tends to
be worse in when the viewer is remote than in a room where "move
closer to the screen" is an issue.  Recent versions of Meetecho
aggravate those situations (rather than helping with them) by
showing slides projected (in at least some ways) in a fairly
small area of the screen, without the possibility of detaching
that area or selectively enlarging it.  One can expand the
picture to full screen, but that means all of the speaker
information (even for speakers sending video), queue
information, chair and participant information, even the ability
to get into the queue, etc., are blocked.  If the chat is off on
a separate screen that helps, but not much.  I'm not sure there
is a satisfactory technical solution for that which would not be
far more complicated (or dependent on over-restrictive
assumptions about user equipment) then it would be worth, but
the IESG and WG Chairs could be doing far more to push back on
the bad practices in the first place.  The LLC leadership could
be doing more too since some of the worst offenders I've seen so
far this week have been presented by LLC staff.


We (and I think that means the IETF and its leadership rather
than anything Meetecho staff are doing or resisting doing)
really need to think carefully about these issues and get them
under control rather than either sending out messages that imply
the the person raising particular issues is too ignorant to use
the tools properly (even when that is true, such ignorance is
often a sign of poor design or weak supporting materials).  And
we better do it before the first "hybrid" meetings because,
while the effective participation of the relatively small number
of active remote contributors prior to IETF 107 could perhaps be
safely ignored as an issue, hybrid nestlings are hard and things
better work for everyone.