Mon blog

Pendant les réunions physiques de l'IETF, il y a divers moyens de suivre la réunion en n'étant pas présent sur les lieux. Entre autres, il y a une pièce XMPP (protocole autrefois nommé Jabber, ce dernier nom restant très répandu) qui permet de poser des questions et de discuter. Une personne dont le rôle est important est le scribe : il ou elle est sur place et son travail est de relayer les remarques et commentaires dans les deux sens, par exemple en allant au micro lire les questions des participants distants.

Ce RFC décrit le travail de ce scribe, qu'on nomme en général en anglais le « Jabber scribe ». Le protocole XMPP (ex-Jabber) est décrit dans le RFC 6120 et le concept de pièces où peuvent être présents plusieurs utilisateurs est dans le XEP-0045. Le rôle du scribe nécessite surtout des compétences humaines (nul besoin d'être un expert XMPP, d'ailleurs l'IETF pourrait utiliser d'autres technologies de messagerie instantanée, cela ne changerait pas grand'chose à son travail).

Les autres techniques utilisées pour permettre aux participants éloignés de suivre (comme Meetecho) sont en général unidirectionnelles. La pièce XMPP est souvent le seul endroit où ces participants peuvent être actifs et pas seulement regarder et écouter. D'où l'importance du rôle du « scribe Jabber ». Il est présent dans les différentes sessions d'une réunion IETF, notamment lors des réunions des groupes de travail, et c'est une ou un volontaire, personne n'est payé et désigné pour être scribe Jabber. Ce RFC décrit cette activité, les qualités nécessaires et comment faire pour être un bon scribe.

Premièrement, le bon scribe doit connaitre son public, les gens pour qui elle ou il travaille (section 2 du RFC). Il y en a trois catégories :

• Les participants distants dont j'ai déjà parlé. Ils regardent les planches qui sont montrées dans la salle, ils écoutent le flux audio, mais ils voudraient aussi pouvoir intervenir (au passage, il faut se rappeler que l'IETF est une organisation ouverte, donc permettre à des gens qui n'ont pas eu le temps ou l'argent de venir est important politiquement).
• Les participants qui sont sur le site mais sont physiquement dans une autre salle. Cela fait partie du folklore IETF de voir quelqu'un dans la salle où se réunit le groupe de travail 1 tout en suivant sur son ordinateur portable les activités des groupes de travail 2 et 3... Comme ils écoutent la salle où ils sont, ils n'ont en général pas branché le flux audio et ont donc besoin d'une pièce XMPP plus bavarde.
• Les participants qui sont dans la salle physique, mais apprécient le fait que, dans la pièce XMPP, on peut communiquer par écrit (cela peut être plus simple pour les non-anglophones) ou simplement qu'on peut discuter sans déranger les autres (du genre « il a bien dit qu'on pouvait raccourcir un changement de clé à une semaine ? Et la section 2.2 du RFC 5011, alors, il y a pensé ? »)

Cette dernière catégorie peut dans certains cas représenter la totalité des gens présents dans la pièce XMPP. Le scribe peut donc demander s'il y a des participants non physiquement présents. Si ce n'est pas le cas, son travail est simplifié puisque tout le monde peut suivre en direct et parler au micro soi-même.

Dans la pièce XMPP, les gens ont uniquement leur identificateur XMPP qui n'est pas forcément leur nom légal. Le scribe qui doit relayer les questions au micro peut leur demander de préciser quel est le nom à annoncer. Si le participant distant veut rester anonyme, il doit le dire explicitement (les présidents du groupe de travail peuvent refuser qu'il y ait des commentaires anonymes, pour des raisons qui sont entre autres liées aux RFC sur la propriété intellectuelle, cf. RFC 8179).

Le scribe Jabber doit aussi se connaitre lui-même (section 3 du RFC). Tout le monde n'est pas un roi de la dactylographie, tout le monde ne parle pas anglais couramment (et on en entend des accents différents dans les réunions IETF) et on n'exige pas du volontaire qu'il soit un professionnel capable de transcrire en temps réel l'intégralité des débats. Si vous êtes volontaire, ajustez donc votre style de scribe à vos capacités.

Les tâches du scribe sont (section 4 du RFC) avant tout de relayer les messages des participants distants. On n'attend pas du scribe qu'il transcrive toute la session sans erreurs sur le canal XMPP. La plupart des scribes se contentent de donner quelques repères (« Joe en est maintenant à la planche 8, sur les problèmes d'implémentation du protocole », « Daneesh demande comment ont été trouvés les paramètres numériques proposés »). Les tâches importantes sont :

• Relayer au micro les commentaires des participants distants,
• Compter les participants distants lors des demandes des présidents de la session du genre « qui a lu le draft ? » ou « qui est volontaire pour faire une revue du document ? » ou « pensez-vous qu'on doive continuer dans cette direction ? » (notez que, dans ce dernier cas, les participants à distance ne bénéficient pas du relatif anonymat de la procédure du hummmmm),

Traditionnellement, le scribe a priorité pour l'accès au micro. C'est notamment utile pour éviter d'aggraver le délai avec lequel les participants distants reçoivent le flux audio et tapent leur contribution.

Il y a aussi d'autres tâches du scribe, moins cruciales (section 5) :

• Indiquer dans la pièce XMPP les noms des gens qui parlent au micro (en théorie, c'est sur le flux audio, mais c'est souvent marmonné en anglais avec un accent...),
• Indiquer le numéro de la planche actuellement affichée sur l'écran (« Now slide 13, on the risks of the new protocol »),
• Superviser via la pièce XMPP la qualité de la retransmission audio (« On n'entend plus rien », « Il y a un écho terrible »),
• Fournir aux participants distants des liens vers les ressources utilisées (notamment les planches de support des exposés).

Certains scribes vont jusqu'à résumer l'essentiel des exposés et des interventions sur la pièce XMPP mais ce n'est pas obligatoire.

La section 6 fournit un certain nombre de conseils aux scribes potentiels, pour qu'ils puissent s'améliorer. D'abord, évidemment, il faut apprendre XMPP et le service XMPP/Jabber de l'IETF. Il faut ensuite, si ce n'est pas déjà fait, installer un client XMPP (une bonne liste est en ligne) et apprendre à s'en servir. Le serveur XMPP de l'IETF ne permet pas la création de compte : il faut avoir un compte existant chez un des innombrables fournisseurs XMPP (comme celui de la Quadrature du Net mais il en existe plein d'autres, XMPP n'étant pas un système centralisé). Vous pouvez tester la connexion aux pièces IETF, même en dehors des réunions, en se connectant à la pièce de bavardage et de test hallway@jabber.ietf.org.

Une fois prêt, le scribe devrait, avant la session, se coordonner avec les présidents de session, apprendre les dernières nouvelles, s'assurer qu'il y a bien une retransmission etc. Il faut aussi vérifier si ces présidents ont des desiderata particuliers pour le scribe, s'ils sont bien d'accord pour que le scribe ne fasse pas la queue pour s'emparer du micro, etc.

Le scribe doit ensuite s'asseoir près du micro. Même si lui ne s'en sert pas, cela lui permettra de voir les badges des intervenants et donc de lire leur nom (ce qui limiterait les innombrables rappels « state your name, please »). Ensuite, il ou elle doit se connecter en XMPP à NOM-DE-LA-SESSION@jabber.ietf.org. Il est recommandé d'avoir également un navigateur Web ouvert, avec plusieurs onglets, affichant l'agenda de la session, la liste des liens vers les documents présentés en session, la page décrivant la retransmission, etc.

Une fois que la session a démarré, le scribe doit :

• Bien s'identifier pour que tout le monde soit au courant de son travail (et ne proteste pas quand elle ou il passe devant tout le monde pour accéder au micro),
• Rappeler aux participants distants qu'il est recommandé de préfixer ses interventions par MIC si on veut les voir relayées au micro,
• Lorsqu'on parle au micro, dire bien clairement qu'on est un relais, qu'on ne parle pas pour soi-même.

Et, à la fin de la session, le scribe met un message clair dans la pièce, indiquant bien que c'est fini et que cela ne sert plus d'envoyer des commentaires.

Le scribe ultra-pro peut bénéficier des conseils de la section 7, qui donne quelques trucs avancés mais utiles. Par exemple, il est intéressant d'avoir deux clients XMPP, connectés à des comptes sur des services différents, pour faire face à certaines pannes ou délais dans le réseau (expérience vécue par les auteurs du RFC). Si le scribe est fana de métrologie, il peut aussi mesurer le délai en écoutant lui-même le flux audio de retransmission, ou en travaillant avec un participant distant de confiance, de manière à communiquer sur la pièce XMPP une estimation de ce délai.

Tout ça, c'était pour quand tout va bien. Mais, dans le monde réel, il y a parfois des gens qui abusent, surtout dans la chaleur d'une vive discussion (IDN, par exemple...). Comment les gérer (section 8) ? Le scribe n'est pas censé tout relayer. Si un participant distant écrit dans la pièce XMPP « MIC: ce connard ne connait rien à la technique et devrait fermer sa gueule », le scribe n'est nullement obligé de répéter ce commentaire verbatim au micro. La meilleure solution est sans doute de demander à l'excité de refaire son commentaire de manière plus constructive.

Ceci dit, le scribe n'a aucune autorité ou pouvoir particulier. Il ou elle est juste un participant IETF parmi les autres. Cela veut dire qu'il n'est pas obligé de faire la police, c'est le rôle des présidents de session.

Retour aux problèmes techniques dans la section 9, qui rappelle les adresses de courrier électronique à utiliser pour signaler les ennuis (de WiFi, par exemple).

Dans le monde moderne, difficile d'échapper aux problèmes posés par l'appropriation intellectuelle. La section 10, consacrée aux IPR (Intellectual Property Rights) rassure le scribe : il n'est qu'un simple relais et les obligations IETF liées à ces IPR (RFC 5378 et RFC 8179) ne le concernent pas. Ce n'est pas lui le contributeur mais la personne dont il relaie le commentaire.

Enfin, la traditionnelle section sur la sécurité (ici, section 11), clôt ce RFC. À part l'hypothèse, théoriquement possible mais qui semble assez lointaine, d'une attaque DoS contre les serveurs XMPP pour empêcher le scribe de faire son travail, cette section note que l'IETF n'a pas actuellement déployé les mécanismes d'enregistrement des utilisateurs dans ses pièces XMPP et qu'il ne faut donc pas se fier aux noms annoncés. Si quelqu'un se prétend Jari Arkko (l'actuel président de l'IETF), rien ne prouve qu'il dit vrai. « Sur XMPP, personne ne sait que vous êtes un chien. »