Subject: Challenges with Jabber clients - Re: Plenary questions

From: Dan York <[email-masked]>
Date: Thu, 8 Nov 2018 05:35:32 +0000

On Nov 8, 2018, Ole Troan <[email-masked] <mailto:[email-masked]>> wrote:

>>> Please refer to the email which was sent to the IETF mailing list on 19 July.  Why did the mistake happen again?
>> 
>> Because I forgot to find a scribe. I?m very sorry about this. (I even added an item to my task manager to remind myself to do this after the last plenary, but it failed to trigger a notification. I already have one correctly set to fire an alarm before the IETF 104 plenary.)
> 
> There were hundreds of people in the room that didn?t notice either, so I think we should take this as a collective failure.

DY> Agreed. It's not all on you, Alissa. When Alice went to the mic, I realized that for the first time in many IETF meetings I was *not* in the plenary Jabber room. At every other IETF meeting I've attended in recent years, I've joined that chat room just to monitor what was going on and be available if remote attendees had questions. Last night I didn't. Had I done so I could have channeled John to the mic (even without formally being the official "scribe"). I'm very glad Alice was there to do so, but others of us could have been there as well.

> Btw: I have experienced that finding working jabber clients for my OS is becoming harder and harder. Is this an indication of jabber in general failing? And if so what are we going to do about it?

DY> I agree with Ole that this is an increasing challenge. For instance, in the latest "Mojave" release of Mac OS, Apple unfortunately just removed Jabber/XMPP support from its Messages app (see https://discussions.apple.com/thread/8553254 <https://discussions.apple.com/thread/8553254> ). The Adium app that many of us on Macs have used hasn't had an update in a couple of years (and the http://adium.im website has pages that are broken, so it's not clear how active the project is). A few of the other clients have their own challenges.

DY> I'm not sure exactly what that means. But perhaps some guidance from those involved with the XMPP side of the IETF about suggestions for clients could be helpful.

Dan

---

From: Mark Andrews <[email-masked]>
Date: Thu, 8 Nov 2018 16:49:32 +1100

I wonder if Metecho could look for MIC: at the start of a jabber comment and add the person to the  speaker queue with the jabber comment as a payload.  The chair could then read out the comment

> On 8 Nov 2018, at 4:35 pm, Dan York <[email-masked]> wrote:
> 
> On Nov 8, 2018, Ole Troan <[email-masked]> wrote:
> 
> DY> I agree with Ole that this is an increasing challenge. For instance, in the latest "Mojave" release of Mac OS, Apple unfortunately just removed Jabber/XMPP support from its Messages app (see https://discussions.apple.com/thread/8553254 ). The Adium app that many of us on Macs have used hasn't had an update in a couple of years (and the http://adium.im website has pages that are broken, so it's not clear how active the project is). A few of the other clients have their own challenges.
> 

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 8 Nov 2018 13:11:55 +0700

After Adium succumbed to bit rot, I looked around and found Swift:
https://swift.im . It seems to work fine on my Mac (still running High
Sierra).

Cheers,
Andy

On Thu, Nov 8, 2018 at 12:36 PM Dan York <[email-masked]> wrote:

> Because I forgot to find a scribe. I?m very sorry about this. (I even
> added an item to my task manager to remind myself to do this after the last
> plenary, but it failed to trigger a notification. I already have one
> correctly set to fire an alarm before the IETF 104 plenary.)
>
>
> There were hundreds of people in the room that didn?t notice either, so I
> think we should take this as a collective failure.
>
>
> DY> Agreed. It's not all on you, Alissa. When Alice went to the mic, I
> realized that for the first time in many IETF meetings I was *not* in the
> plenary Jabber room. At every other IETF meeting I've attended in recent
> years, I've joined that chat room just to monitor what was going on and be
> available if remote attendees had questions. Last night I didn't. Had I
> done so I could have channeled John to the mic (even without formally being
> the official "scribe"). I'm very glad Alice was there to do so, but others
> of us could have been there as well.
>
> Btw: I have experienced that finding working jabber clients for my OS is
> becoming harder and harder. Is this an indication of jabber in general
> failing? And if so what are we going to do about it?
>
>
> DY> I agree with Ole that this is an increasing challenge. For instance,
> in the latest "Mojave" release of Mac OS, Apple unfortunately just removed
> Jabber/XMPP support from its Messages app (see
> https://discussions.apple.com/thread/8553254 ). The Adium app that many
> of us on Macs have used hasn't had an update in a couple of years (and the
> http://adium.im website has pages that are broken, so it's not clear how
> active the project is). A few of the other clients have their own
> challenges.
>
> DY> I'm not sure exactly what that means. But perhaps some guidance from
> those involved with the XMPP side of the IETF about suggestions for clients
> could be helpful.
>
> Dan
>
>

---

From: Yoav Nir <[email-masked]>
Date: Thu, 8 Nov 2018 14:09:02 +0700

I’ve been using Psi: https://psi-im.org/index.php <https://psi-im.org/index.php>

Not particularly pretty, but it gets the job done.

> On 8 Nov 2018, at 13:11, Andrew G. Malis <[email-masked]> wrote:
> 
> After Adium succumbed to bit rot, I looked around and found Swift: https://swift.im <https://swift.im/> . It seems to work fine on my Mac (still running High Sierra).
> 
> Cheers,
> Andy
> 
> 
> On Thu, Nov 8, 2018 at 12:36 PM Dan York <[email-masked] <mailto:[email-masked]>> wrote:
>> There were hundreds of people in the room that didn?t notice either, so I think we should take this as a collective failure..
> 
> DY> I agree with Ole that this is an increasing challenge. For instance, in the latest "Mojave" release of Mac OS, Apple unfortunately just removed Jabber/XMPP support from its Messages app (see https://discussions.apple.com/thread/8553254 <https://discussions.apple..com/thread/8553254> ). The Adium app that many of us on Macs have used hasn't had an update in a couple of years (and the http://adium.im <http://adium.im/> website has pages that are broken, so it's not clear how active the project is). A few of the other clients have their own challenges.
>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 8 Nov 2018 08:29:46 +0100 (CET)

I just use the Meetecho recording page. Yes, I need to watch the stream 
even if I do not need it (because I am in the physical room), but I do get 
a combined view of chat room, live video feed, and slides in my browser 
without needing to install any other software or having an account 
anywhere.

When I am a jabber scribe, I type into the chat room the name of the 
person speaking at the mic as people walk up to the mic (I read their 
badge (PLEASE PEOPLE, HAVE YOUR BADGES EASILY READIBLE!), and this means 
together with the audio, video and slides, people speaking into the mic 
are identified by name and the note taker can use this to make sure the 
notes are correct).

I also start each session by stating that I am the jabber scribe and that 
people who want things relayed to the mic should preface their statement 
with "to mic:". This has worked well for me and the sessions I jabber 
scribe.

I also recommend that the chairs in sessions monitor the jabber room. Some 
do already, but I recommend everybody to do so.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Dave Cridland <[email-masked]>
Date: Thu, 8 Nov 2018 10:03:26 +0000

> active the project is). A few of the other clients have their own
https://swift.im/ works fine on a Mac, and seems good enough for me (though
I only use a Mac at all under duress). Swift is fully supported, if you
want, by Isode (who I used to work for, but didn't work at all on Swift
beyond the logo).

There are also a bunch of really quite solid web clients - XMPP over a
websocket works as well as it does over TCP.

Jabber (or XMPP) isn't failing, but it is being driven from the mainstream
by the closed silos, so generic clients are comparatively rare. Instead,
there are either systems that gateway through (Skype for Business does, I
think - Lync certainly did), or else there are various bespoke clients for
specific use-cases. Finally, various public services - and these are fairly
rare, sadly - include a webclient tied to their service. This isn't
particularly unusual in our world - you similarly cannot find a decent
desktop email client anymore, since everyone uses webmail.

---

From: John C Klensin <[email-masked]>
Date: Thu, 08 Nov 2018 11:16:38 -0500

Several comments from the perspective of someone who is remote
at most IETF meetings these days but often has a lot of comments
and questions....

--On Thursday, November 8, 2018 08:29 +0100 Mikael Abrahamsson
<[email-masked]> wrote:

> I just use the Meetecho recording page. Yes, I need to watch
> the stream even if I do not need it (because I am in the
> physical room), but I do get a combined view of chat room,
> live video feed, and slides in my browser without needing to
> install any other software or having an account anywhere.

This certainly works.  However, at least for those of us with
significant available screen real estate when working remotely,
it has two disadvantages.  

(i) If one does want to watch the panel with the slides and the
speaker stream, there is a certain amount of nuisance switching
back and forth required that makes it hard to keep track of the
chat activity as well.   It is much easier if the latter is in a
completely separate window that can be positioned as needed.
But that requires a Jabber client that is not embedded in a web
browser, much less in Meetecho, unless one wants to run two
separate browser windows.

(ii) The input window is tiny (one line and narrow), making
typing a question or comment more complicated than "well, the
room isn't too cold where I am" or "Joe Bloggs at mic" and
proofreading it without sending much more complex and
time-consuming than it should be.  I have given up: I compose
non-trivial remarks and questions in a text editor, check them,
and then paste them into Meetecho and send them.  Still not
optimal.

Neither of those issues is particularly relevant to someone
monitoring Jabber in the meeting room as distinct from (a subset
of) those of us was are working remotely.  (The Meetecho team
knows how I feel about these things and I understand why fixing
them within Meetecho is probably not the right solution.)

> When I am a jabber scribe, I type into the chat room the name
> of the person speaking at the mic as people walk up to the mic
> (I read their badge (PLEASE PEOPLE, HAVE YOUR BADGES EASILY
> READIBLE!), and this means together with the audio, video and
> slides, people speaking into the mic are identified by name
> and the note taker can use this to make sure the notes are
> correct).

Dan and several others do this as well.   It may not have been
said publicly before, but it is hugely helpful and not just for
note takers.  For those of us who are remote, being able to know
who is speaking is very important -- it provides context for
those of us who have been around for a while and may help
newcomers (in person as well as remote) get to know the
community.  While people are supposed to announce their names,
many forget and even more, who know their own names and are
anxious to get on with their comments, tend to go to the
microphone and quickly mumble something entirely unintelligible
to those listening remotely and trying to simultaneously listen
to (not always perfect) audio and track Jabber and the slides.
Video rarely helps much either, as, in most WGs, the Meetecho
camera almost always stays pointed at the front of the room
(main microphone or chair's table).  (Not the fault of the
Meetecho team -- there are no solutions that that problem which
generalize and are optimal at least unless we are willing to go
to the considerable additional cost --in people, rather than
technology-- of running two cameras and possibly having both
feed to the client screen).  So, much of the time, "XYZ at mic"
is our only real clue about who is speaking.

> I also start each session by stating that I am the jabber
> scribe and that people who want things relayed to the mic
> should preface their statement with "to mic:". This has worked
> well for me and the sessions I jabber scribe.

Oddly, it has also been a source of confusion. 

<small diversion>
It seems to have not been publicized as well as the Meetecho
team and apparently the IESG thought it was, but there are now
two ways for a remote participant to inject a comment or
participate in a discussion.  One, as we know, is to go through
Jabber and use "to mic:" or "MIC:".  The other is to use
Meetecho's "remote queue" facility, which actually gets the
remote participant into a queue analogous the the microphone
line(s) (Anyone who is reading this who doesn't know, look for
the little hand next to your name above the participant panel.)
WHen it is feasible to use, it has at least three advantages
over typing a comment into Jabber: (i) It doesn't require typing
before making the request to be heard or then waiting for
someone to get in the back of the mic line, which lowers the
odds that the discussion will have moved on to something else
before the comment is heard.   (ii) If one is actually trying to
participate in a discussion, being "live" on audio and video
allows interactions much more like standing at a floor
microphone and using a human relay for typed text.  And (iii)
Meetecho notifies the WG Chairs directly (and apparently makes
noise, rather than requiring active monitoring) when there is
someone in queue.   Comments from IESG members (and especially
Alissa) seem to imply that the remote queue mechanism is not
only their preferred choice but that they think most people have
switched to it rather than using Jabber.

The bad news is that, at least from my experience, the facility
is still in need of considerable tuning, not in how Meetecho
works but in how WG Chairs and equivalent handle it.  More
training needed and all that.

At the same time, I think we need to keep Jabber and keep it
working for remote input until we discover an equivalent
solution.  The remote queue arrangements don't work for anyone
who is in a location where their talking to the the computer or
running video input would be disruptive or violate local rules.
Sending audio and video from the client requires significantly
more high-quality bandwidth than simply receiving Meetecho and
occasionally typing a few lines into Jabber, and some IETF
participants may not have that all of the time (or ever).
People who feel uncertain about their English may be more
comfortable typing and proofreading than speaking (although my
preference would be to convince them that we are less fierce
than we often appear and that, if they speak slowly and clearly,
we will happily adjust).  And some comments may be brief and
self-contained enough that opening up an A/V feed from the
client would be rather high overhead.   There may be other
reasons in particular WGs or other sessions, including the
observation that Jabber input makes a record of the question
even if it is not repeated at room microphone while a request to
get in the remote queue leaves few tracks if the chair doesn't
turn microphone of the person making the request on.
</small diversion>

When I've seen something equivalent to "if you want something
repeated in the room, start it with 'to mic:'", I take it to
mean "Jabber input is preferred in this session to use of remote
queues".  Maybe that will go away over time as we all get used
to the remote queue facility but, for the near term, I'd much
prefer to see something more like "if you have input for the
room and don't find the remote queue facility convenient, type
your message into Jabber and preface it with 'MIC:'"
 
> I also recommend that the chairs in sessions monitor the
> jabber room. Some do already, but I recommend everybody to do
> so.

Good idea but, especially for very controversial discussions and
plenaries, may not be realistic.

best,
   john

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 8 Nov 2018 18:01:59 +0100 (CET)

> your message into Jabber and preface it with 'MIC:'"

I have never considered that people might take it this way. For me it was 
never an encouragement, it was mostly just to announce my services as a 
relayer of information. I will in the future also try to mention the 
remote queue facility so that people consider both. Thanks for sharing 
your view on this topic so I can improve.

My experience with remote queue facility is that many people seem not used 
to remote voice/video setup and tend to have problems getting their 
voice quality right. I do voice/video conferencing from my computer ~10 
times a week and this is a common thing. Many things can go wrong with 
VoIP and it does require a well-working setup for things to work well. I 
encourage people to test their setup before the meeting. I've seen 
everything from choppy audio which typically (from my experience in 
fault-finding VoIP issues) tend to be bad wifi connectivity or WAN 
connectivity (bufferbloat), to clipping microphones due to either bad 
quality microphone or wrong gain setting, to all kinds of other problems.

---

From: John C Klensin <[email-masked]>
Date: Thu, 08 Nov 2018 12:57:04 -0500

--On Thursday, November 8, 2018 18:01 +0100 Mikael Abrahamsson
<[email-masked]> wrote:

>> mean "Jabber input is preferred in this session to use of
>> remote queues".  Maybe that will go away over time as we all
>> get used to the remote queue facility but, for the near term,
>> I'd much prefer to see something more like "if you have input
>> for the room and don't find the remote queue facility
>> convenient, type your message into Jabber and preface it with
>> 'MIC:'"
> 
> I have never considered that people might take it this way.

Perhaps I'm an anomaly, but I've had enough experience with WGs
in which people in the remote queue are just not called on or
gotten to that, absent explicit confirmation that a particular
WG is actually using it, I end up relying on small clues, even
somewhat suspect ones.  I am, however, at least as concerned
about giving people who are remote with less experience of the
IETF's practices and tools than I have good hints about what is
available.

> For me it was never an encouragement, it was mostly just to
> announce my services as a relayer of information. I will in
> the future also try to mention the remote queue facility so
> that people consider both. Thanks for sharing your view on
> this topic so I can improve.

Understood and appreciated.

> My experience with remote queue facility is that many people
> seem not used to remote voice/video setup and tend to have
> problems getting their voice quality right. I do voice/video
> conferencing from my computer ~10 times a week and this is a
> common thing. Many things can go wrong with VoIP and it does
> require a well-working setup for things to work well. I
> encourage people to test their setup before the meeting. I've
> seen everything from choppy audio which typically (from my
> experience in fault-finding VoIP issues) tend to be bad wifi
> connectivity or WAN connectivity (bufferbloat), to clipping
> microphones due to either bad quality microphone or wrong gain
> setting, to all kinds of other problems.

Indeed.  And that is precisely why Meetecho suggests running
their test procedures and sorting things out as needed well
before the relevant meeting or WG session.   It is also why they
try to require that and somewhat more for anyone who is planning
to do a presentation from a remote location rather than just
participating.   Again, this is no one's fault in particular
(although, as with many other things, the finger for making sure
the right things happen ultimately points at the IESG) but the
community needs, IMO, to do _much_ better at cluing people,
especially newcomer-type people, in.

Again, thanks for your help.  I very much appreciate anyone who
is willing to act as a Jabber scribe, especially those who take
is seriously and try to do a good job.

    john