Network Working Group | P. Saint-Andre |
Internet-Draft | &yet |
Intended status: Informational | D. York |
Expires: October 17, 2015 | Internet Society |
April 15, 2015 |
The Jabber Scribe Role at IETF Meetings
draft-saintandre-jabber-scribe-01
During IETF meetings, individual volunteers often help sessions run more smoothly by relaying information back and forth between the physical meeting room and an associated textual chatroom. Such volunteers, commonly called "Jabber scribes", might benefit from the suggestions provided in this document.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 17, 2015.
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
During IETF meetings, individual volunteers often help sessions run more smoothly by relaying information back and forth between the physical meeting room and an associated textual chatroom. Because these chatrooms are currently implemented using Jabber/XMPP technologies (see [RFC6120] and [XEP-0045]) the role is commonly referred to as that of a "Jabber scribe".
This role is important because it is the primary way for a remote attendee to provide feedback or comments back into most IETF meeting sessions. Although there are multiple ways that a remote attendee can listen and follow along, the chatroom provides a method of returning feedback to the physical meeting in something close to real time. These methods hold true for IETF working group sessions, IRTF research group sessions, IETF "birds of a feather" (BoF) sessions, and similar sessions at IETF meetings.
This document provides suggestions for fulfilling the role of a Jabber scribe, based on the authors' personal experience as well as input from other individuals who frequently volunteer as Jabber scribes.
The participants in a chatroom typically fall into three categories, labelled here for ease of understanding:
Chatroom participants are usually identified by a "nickname" or "handle" rather than a full name. This can be confusing to scribes, because they don't always know who is providing questions or comments to be relayed. A scribe should feel free to ask for clarification so that the identity of the remote participant can be communicated at the microphone.
Different people have different aptitudes and skills. Although some people who volunteer to act as Jabber scribes are able to provide a fairly complete transcription of what is said and done in the physical meeting room, that is not the expectation for most volunteers (don't be scared off by the word "scribe"). Fulfilling the primary tasks described in the next section is not a significant burden for most volunteers, and can be an enjoyable way to participate in a session. This document attempts to describe the experience and provide some helpful guidance, but if you are thinking about volunteering then you might also ask other volunteers about their experience. Knowing your aptitudes and skills (e.g., perhaps you are not a great typist) can help you understand the level of involvement you are comfortable with.
The primary "customers" for a Jabber scribe are the remote participants, and those customers are served in real time. A scribe can assume that remote participants have access to at least the audio stream and perhaps also video for a session (except in extraordinary circumstances, such as when technical problems occur with the streaming facilities). Even though chatroom sessions are logged during IETF meetings and these public logs can be a useful adjunct to the historical record, a scribe is not expected to transcribe what is said and done during the session. Instead, the primary role of a scribe is to act as a relay between the physical room and the remote participants.
In particular, individuals who volunteer for the role of Jabber scribe usually complete the following tasks:
It is the convention in most sessions that the Jabber scribe has the privilege to go to the front of the microphone line to relay information from remote participants. Some Jabber scribes choose to exercise that privilege while others choose to wait in line along with the participants in the physical meeting rooom. However, be aware that because of lag (often 20 seconds or more) between in-room discussions and the audio stream (as well as the inevitable delay while a remote participant types a question or comment to be relayed), it can be helpful for the scribe to "jump the queue" so that such questions and comments are not stale by the time they are relayed to the microphone.
Additionally some Jabber scribes often complete the following tasks:
Although Jabber scribes are not generally expected to transcribe the complete contents of conversations that happen in the physical room to the chatroom, they sometimes relay the gist of such conversations, especially during ad-hoc discussions for which slides are not available. (By prior arrangement between the session chairs and the Jabber scribe, actual transcription might be expected for particular sessions.)
Experience has shown that the following behaviors make it easier to act as a Jabber scribe.
An overview of the IETF Jabber service can be found at <http://www.ietf.org/jabber/>. Many common instant messaging clients support the Jabber/XMPP protocols, and at the time of writing a list of such clients can be found at <http://xmpp.org/xmpp-software/clients/>. Because the IETF Jabber service provides chatrooms only and does not enable direct registration of user accounts, you will need to create a user account at another service; one list of such services can be found at <https://xmpp.net/directory.php>. Not all clients support the ability to join a chatroom, so you might want to test your preferred software in advance of the meeting (the hallway@jabber.ietf.org room is a good place to test). Although the exact user interface for joining a chatroom depends on the software you are using, typically such software will have a "join room" option that prompts you to provide the entire room address (e.g., "hallway@jabber.ietf.org") or separately provide the name of the room (e.g., "hallway") and the domain of the chatroom service (e.g., "jabber.ietf.org"). Asking your fellow IETF participants about their preferred software applications can be a good way to learn about Jabber/XMPP clients that you might want to use.
If you have volunteered before the session:
As you are getting settled and ready for the meeting to start:
Identifying one or more assistants is particularly useful if you want to go up to the microphone to speak as an individual or if you need to take a break or step out of the physical room at some point.
As you perform your role during the session:
As you wrap up your scribing at the end of the session:
If you need to report a problem during an IETF meeting (e.g., problems with media streaming), at the time of this writing there are several ways to do so:
It can be helpful to run two separate Jabber clients connected to two separate Jabber servers, in order to prevent delays if one of the servers experiences an outage during the session (yes, it has happened).
If you have a chance to do so, you may want to measure the lag time between when something is said in the physical room and when it is heard on the audio stream and then let the remote participants know the length of the delay. This could be accomplished by either listening to the audio stream yourself or working with a remote participant who you know is on the audio stream.
This document requests no actions from the IANA.
Although XMPP multi-user chat rooms [XEP-0045] can be configured to lock down nicknames and require registration with the chatroom in order to join, at the time of this writing IETF chatrooms are not so configured. This introduces the possibility of social engineering attacks on discussions held in IETF chatrooms. It can be helpful for Jabber scribes to be aware of this possibility.
In addition, denial of service (DoS) attacks of various kinds are possible, e.g., flooding a chatroom with unwanted or automated traffic.
[RFC6120] | Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, March 2011. |
[XEP-0045] | Saint-Andre, P., "Multi-User Chat", XSF XEP 0045, February 2012. |
Thanks to Dan Burnett, Dave Crocker, Wes George, Janet Gunn, Joel Halpern, Jelte Jansen, Michael Jenkins, Olle Johansson, Warren Kumari, Jonathan Lennox, Alexandre Petrescu, Melinda Shore, Hugo Salgado, Yaakov Stein, and Greg Wood for their helpful comments and suggestions.