Saucisse Royale emersion Statut : Protocole Standard 23 nov. 2016 Protocole pour faire taire les insolents : TG SO6RFC3 Contexte Dans la période du 18 octobre 2016 au 2 novembre 2016, un certain utilisateur de IRDille a communiqué son mécontentement face à des abus d'utilisateurs particuliers du système de traitement automatisé de données. Cet individu poussé à bout témoigne : « je suis choqué », « j'ai 1000 frissons, j'ai envie de chialer », « j'étais en PLS intense ». Dans un tel contexte de tension sociale, il n'eût pas été envisageable de laisser la situation aller de pis en pis. C'est pourquoi un protocole permettant de faire cesser ces messages indésirables fût jugé absolument nécessaire. Ce document ne décrira qu'un protocole, et pas un peu plus. Table des matières 1. Rappels de notation 2. Protocole TG 2.1. Généralités 2.2. États 2.3. Messages 3. Considérations concernant la sécurité 1. Rappels de notation o TG signifie TG o Bit : zéro (0) ou un (1) o Octet : unité de huit (8) bits 2. Protocole TG 2.1. Généralités Le protocole TG est AgNOSTIQUE Du PrOTOCOLE (AgDuPr), c'est-à-dire qu'il fait abstraction des couches inférieures sous-tendant l'échange de données, sous réserve de certaines conditions. Le protocole sous-tendant l'échange de données doit comprendre la notion de « message ». Nous définissons un « message » comme un ensemble ordonné de signaux transmis entre un émetteur et un récepteur par un média. Si cette contrainte est vérifiée par le protocole sous-jacent, alors on dit que ce protocole supporte TG. On utilisera le terme de posteur pour désigner l'initiateur de l'envoi d'un message. On nommera alors destinataires l'ensemble des utilisateurs qui recevront un message envoyé via le biais du protocole sous-tendant à l'échange de données, et destinataire un élément de cet ensemble. TG offre deux mécanismes utiles à la gestion des abus : l'un permet de demander à un utilisateur de ne plus envoyer de messages indésirables, l'autre est utile à l'annulation de cette demande. On dit que TG s'applique à un destinataire lorsque les demandes s'adressent à ce destinataire. Ce destinataire auquel TG s'applique est appelé ci-après l'appliqué. On pourra recontrer dans la suite de ce document « MI » pour message indésirable. La définition de la notion de message indésirable, et la classification des messages entre messages indésirables et messages non indésirables sont subjectives aux appliqués et aux posteurs, aussi ce document ne présentera pas de critère précis et obligatoire concernant ces aspects. Cependant, la définition (implicite ou explicite) de la notion de message indésirable DOIT être la même pour toutes les demandes effectuées par des posteurs différents, à appliqué fixé, autrement dit les états TG d'un appliqué (voir ci-dessous) ne DOIVENT PAS dépendre de l'initié. Une telle définition POURRAIT être « les messages indésirables sont excatement les messages spontanés ne correspondant pas à une sollicitation explicite » où la signification exacte de « sollicitation explicite » est à définir. Dans tous les cas, la définition choisie DEVRAIT relever du bon sens, et ne pas être intentionnellement choisie de sorte à annuler l'effet du TG. Dans un cadre où il n'y a aucun destinataire, TG DEVRAIT s'appliquer à la personne dénomée delthas mais PEUT n'avoir aucun effet. Dans le cadre où il y a exactement un destinataire, TG DOIT s'appliquer à cet unique destinataire, mais PEUT également s'appliquer à la personne dénomée delthas. Dans le cadre où il y a plusieurs destinataires au sens strict, TG DOIT s'appliquer au moins à tous les destinataires supportant TG. Dans le cas où un destinataire supporte le protocole TG, il est dit TG-compliment. Il PEUT alors annoncer ce support, et si le protocole sous-jacent le supporte, DEVRAIT ajouter TG à la liste de ses capacités. 2.2. États La table ci-dessous présente la liste des états TG d'un utilisateur. L'état initial d'un utilisateur est laissé libre à ce dernier. +---------------+---------------------------+---------------------------------+ | Nom de l'état | Effet | État(s) suivant(s) potentiel(s) | +---------------+---------------------------+---------------------------------+ | TG | Ne peut pas envoyer de MI | TGNON | | | | | | TGNON | Peut envoyer des MI | TG | +---------------+---------------------------+---------------------------------+ Table des états 2.3. Messages La table ci-dessous présente la liste des messages TG qui peuvent être envoyés. Lors d'une implémentation de ce protocole, il est conseillé de placer les valeurs devant être envoyées (ci-après le « contenu du message ») dans des constantes afin de ne pas avoir besoin de les encoder « en dur » dans un programme informatisé. +----------------+---------------------------------------+--------------------+ | Nom du message | Effet | Contenu du message | +----------------+---------------------------------------+--------------------+ | TG | Demande d'arrêt d'envoi de MI | !tg | | | | | | TGNON | Demande d'arrêt d'arrêt d'envoi de MI | !tgnon | +----------------+---------------------------------------+--------------------+ Table des messages Les messages ne DOIVENT pas être sensibles à la casse, c'est-à-dire que le fait d'envoyer des majuscules au lieu de minuscules ou inversement est un message TG valide. o TG : le posteur indique que l'appliqué DOIT cesser d'envoyer des messages indésirables et rentrer dans l'état TG. Dans le cas où l'appliqué est déjà dans l'état TG, l'appliqué DOIT ne rien faire. Dans le cas contraire, il PEUT avant de passer dans l'état TG envoyer un dernier MI (dit « commémoratif ») pour signifier au posteur que le TG a été pris en compte avec succès. Ce message ne DOIT pas excéder 587 octets, mais PEUT être plus court (un protocole sous-jacent peut également limiter la taille des messages envoyés par un posteur). Après ce message, plus aucun MI ne peut être envoyé tant que l'état de l'appliqué est l'état TG. o TGNON : le posteur indique que l'appliqué PEUT cesser de ne pas envoyer des messages indésirables et DOIT passer dans l'état TGNON. Dans le cas où l'appliqué est déjà dans l'état TGNON, l'appliqué est libre de réagir comme il le souhaite. Dans le cas contraire, avant de passer dans l'état TGNON, il DOIT envoyer un message (dit « enchanté ») pour signifier au posteur que le TGNON a été pris en compte avec succès. Ce message PEUT excéder 587 octets, et DOIT contenir au moins un caractère alphanumérique. Après ce message, de nouveaux messages indésirables peuvent être envoyés tant que l'état de l'appliqué est l'état TGNON. Note : Dans le cas de l'utilisation d'un média ne permettant pas facilement un décompte d'octets, il est à la charge de l'envoyeur du message de réaliser la transcription en une chaîne de caractères des messages. Le décompte d'octets DOIT se faire sur des chaînes de caractères encodées avec le jeu de caractères Windows 1252. 3. Considérations concernant la sécurité Il n'y a pas de problème de sécurité connu pour ce protocole.