SPARKNET(tm) R‚seau Francophone International Copyright 1993-1995, Philippe Chev‚ Version 2 Revision 0 (1er Janvier, 1995) I. Le r‚seau SPARKNET ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ SPARKNET est un r‚seau francophone cr‚‚ le 1er Juillet 1993 par Philippe Chev‚, SysOp d'Hermes Center BBS (France) et par Olivier Langlois, SysOp d' Electron BBS (France). Le r‚seau est distribu‚ au format PKT (Technologie fidonet) sous la Zone 74, gratuitement. Depuis le 1er Janvier 1995, le r‚seau est administr‚ par un 'Comit‚ de Pilotage' (CP) constitu‚ de 6 membres actifs du r‚seau. La langue officielle du r‚seau, et ce qui en fait sa particularit‚ premiŠre, est le Fran‡ais. Toutefois, les messages en anglais seront tol‚r‚s pourvu qu'ils soient peu nombreux. II. TERMINOLOGIE SPARKNET ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ II.1 - Zone Coordinateur (ZC) ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Le ZC est ‚lu pour 4 ans et repr‚sente la plus haute autorit‚ du r‚seau. Il n'est pas revoquable sauf d‚cision unanime des 5 autres membres du comit‚ de pilotage. Ces fonctions principales sont: - La nomination des 5 membres du Comit‚ de Pilotage - La nomination des Coordinateurs R‚gionaux (RC & REC) - La nomination des HOSTS - La nomination des Animateurs/Mod‚rateurs de conf‚rences sur proposition du Comit‚ de Pilotage. - L'‚laboration et maintenance des NodeList et PointList - Contr“le & Coordination du r‚seau (ZEC). - Publication des d‚cisions du Comit‚ de Pilotage - Mod‚ration des conf‚rences SYSOPS et d'adminstration du r‚seau - Fait respecter les d‚cisions des mod‚rateurs - Assure implicitement les fonctions de RC & REC France jusqu'au 1er Janvier 1997. - En cas d'‚galit‚ lors d'un vote ou referendum, la d‚cision du ZC est finale. Le ZC peut prendre toute d‚cision concernant le r‚seau avec effet imm‚diat en attendant une d‚cision du comit‚ de pilotage. Enfin le ZC peut revoquer tout RC, HOST, HUB, NODE, POINT ou membre du comit‚ de pilotage en cas de publication de documents ou messages confidentiels. Sont consid‚r‚s comme documents confidentiels : Les Netmails, toutes les conf‚rences d'administrations, texte ou message comportant la mention: "Publication confidentielle du r‚seau SPARKNET" "R‚glementation SPARKNET II.1 - Version 2 Revision 0" II.2 - Coordinateur R‚gional (RC & REC) ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Le Coodinateur R‚gional, nomm‚ par le ZC est responsable de l'administration d'un Pays et assure l'‚change de courrier (REC) avec le ZEC. Il g‚re son pays en respectant les r‚gles du r‚seau et doit faire appliquer imm‚diatement toute d‚cision du comit‚ de pilotage ou du ZC. Il est responsable de l'admission des nodes, Hosts et Hubs de son pays et transmet r‚gulierement ses portions de NodeList & PointList au ZC. Le REC doit se doter de tous les outils n‚c‚ssaire au bon fonctionnement des echomails : TossScan, Mailer & Tracker perfectionn‚. II.3 - Coordinateur de NET (NC & NEC) ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Le coordinateur Nodelist (NC) assure la maintenance d'une portion de la Nodelist et de la PointList pour une partie du r‚seau dont il a la charge. Seul un ZC, RC ou HOST peut assurer la fonction NC. Il doit transmettre r‚guli‚rement ses modificiations … son responsable hi‚rarchique Le coordinateur Echomail (NEC) assure, l'admission de nouveaux Nodes ou Hubs et l'‚change de courrier pour sa r‚gion (NET). II.4 - Sous-Coordinateur de NET (HUB) ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Un HUB prend en charge l'‚change de courrier d'une partie d'une r‚gion pour simplifier les op‚rations d'un Host ou quand la concentration de Nodes sur une r‚gion impose une restructuration du NET. II.5 - Node Administratif ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Un Node administratif h‚berge g‚n‚ralement des applications d‚centralis‚es dont la gestion n'est pas assur‚e par le ZC : Maintenance des fichiers d'informations SPARKNET, Bureau de Vote, etc... Les nodes administratifs sont nomm‚s par le comit‚ de pilotage. II.6 - Comit‚ de Pilotage (CP) ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Le comit‚ de pilotage prend toutes les d‚cisions concernant le d‚veloppement et le bon fonctionnement du r‚seau. Il est constitu‚ de six membres actifs du r‚seau nomm‚s par le ZC qui est membre auto- matiquement. Ses fonctions sont illimit‚es mais concernent principalement: - L'approbation pour la cr‚ation ou la suppression de Services. - L'approbation pour la cr‚ation ou la suppression de conf‚rences r‚sultant d'un vote public de tous les participants SPARKNET. - Approbation pour la radiation d'un RC, HOST, NODE, POINT. - L'approbation pour la cr‚ation ou la suppression de conf‚rences r‚sultant d'une proposition d'un membre du comit‚ de pilotage. - Droit de Veto sur toutes d‚cisions autoris‚es par les fonctions de RC, REC, NC, NEC ou HOST. La publication r‚sultant d'un vote ou d'une d‚cision du comit‚ de pilotage est assur‚ exclusivement par le ZC. Les membres du comit‚ de pilotage sont astreints … observer les r‚gles suivantes : - Confidentialit‚ totale sur toute discussion, toute d‚cision ou tout message relevant d'un d‚bat en cours ou termin‚. - Ne jamais transmettre la conference reserv‚e aux discussions du comit‚ de pilotage … une personne non membre du comit‚. - Ne jamais engager de pol‚mique en conf‚rence publique ou priv‚e. - Se prononcer sur tous les votes ou referendums. Les votes nuls ou blancs ne sont pas accept‚s. - Tous les membres du comit‚ de pilotage doivent poller le ZC aumoins deux fois par semaine pour r‚cup‚rer la conf‚rence r‚serv‚e au comit‚ de pilotage et pour recevoir les netmails en attente. - Pr‚venir par netmail les autres membres du CP en cas d'anomalies graves dans le r‚seau ou dans les conf‚rences du r‚seau. Le Comit‚ de Pilotage ne peux s'opposer … toutes d‚cisions relevant des fonctions du ZC d‚finies en section II.1 III. REGLEMENTATION SPARKNET ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ III.1 TYPE DE MESSAGES ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Toutes les conf‚rences de SparkNet transitent uniquemement des messages Publiques. Les messages crypt‚s ou UUencod‚s ne sont pas admis. III.2 ALIAS ÄÄÄÄÄÄÄÄÄÄÄ Aucune conf‚rence de SparkNet ne devra accepter les Alias. III.3 TENEUR DES MESSAGES ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Seront imm‚diatement mod‚r‚s : ù Les messages d'insultes, ù Les incitations au piratage en tout genre et … la copie illicite, ù L'incitation … la consommation ou … la vente de drogue ou d'alcool ù Les messages contentant des num‚ros de t‚l‚phone ou des adresses en vue de porter pr‚judice … leur propri‚taire, ù D‚claration de codes de registration, . Une copie ou un forward d'un NETMAIL ou message priv‚ sans l'accord de l'auteur. ù Et toutes autres activit‚s ill‚gales. III.4 ORIGIN LINES ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ L'origin line doit imp‚rativement se pr‚senter comme suit: þ SparkNet þ Nom du BBS þ Adresse ou þ SparkNet þ POINT DE Nom du BBS þ Adresse G‚n‚ralement l'adresse est ajout‚e automatiquement par le TosScan. Dans tous les cas, l'Origin Line ne devra PAS d‚passer les 50 caractŠres III.5 TRANSFERTS & ABSENCES ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Un BBS supportant SparkNet doit effectuer au minimum 2 transferts de paquets de courrier par semaine vers son host ou Rc. Dans le cas d'une impossibilit‚ due … un d‚placement ou … une panne de mat‚riel, le SysOp doit faire en sorte de pr‚venir son Hub de la dur‚e de son absence. Tout arrˆt de transfert pendant une dur‚e sup‚rieure … 5 semaines entrainera la d‚connexion automatique du r‚seau. III.6 FICHIERS D'INFORMATIONS DU RESEAU ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Tous BBS membre du r‚seau SPARKNET doit disposer de la derniŠre version des fichiers d'informations en download et en File Request en respectant la codification des Magic names du r‚seau. --> Consulter le fichier de contr“le des fichiers : SK_FILES.TXT III.7 CONFERENCES SPECIALES ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Certaines conf‚rences du r‚seau sont r‚serv‚es en lecture & ‚criture et ne doivent donc en aucun cas ˆtre lisibles par un simple utilisateur, d'autres ne sont acc‚ssibles qu'en lecture uniquement. --> Consulter le fichier de contr“le des conf‚rences : SK_CONFS.TXT III.8 POINTS DU RESEAU ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Il est interdit de redistribuer les conf‚rences du r‚seau … des pointsnon inscrits dans la pointlist SPARKNET officielle. Les nouveaux point doivent utiliser la conf‚rence SK_TEST pour effectuer les tests d'int‚gration dans le r‚seau et doivent attendre le feu vert de leur BOSS avant de commencer l'ECHOMAIL dans les autres conf‚rences. III.9 MESSAGES D'ADMINISTRATION ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Les messages d'annonces et d'administration du r‚seau, r‚sultant g‚n‚ralement d' une d‚cision du comit‚ de pilotage, post‚s exclusivement par le ZC ne doivent faire l'objet d'aucune r‚ponse en conf‚rence publique. Toutes r‚ponses … un message de ce type sera imm‚diatement mod‚r‚ par le ZC ou un membre du Comit‚ de Pilotage. Ces messages sont toujours pr‚fix‚s par l'entˆte suivante: "Annonce Officielle du r‚seau SPARKNET" "Ne pas r‚pondre publiquement … ce message" "R‚glementation SPARKNET III.9 - Version 2 Revision 0" III.10 JEU DE CARACTERES ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Les codes ANSI sont accept‚s dans toutes les conf‚rences de SPARKNET Toutefois, quelques rŠgles sont … observer lorsque vous l'utiliserez dans vos messages: à Il est d‚fendu d'utiliser l'effacement d'‚cran dans un message, à Il est strictement d‚fendu d'utiliser des codes musicaux au sein de vos messages (sauf en conf SK_MUSIC), à Il est d‚fendu d'utiliser des codes de nature … d‚t‚riorer l'affichage des messages qui suivront sur le BBS, à L'utilisation des dessins en mode ANSI devra ˆtre faite avec mod‚ration, à Aucun dessin ansi ne devra prendre plus d'une page. Les SysOps h‚bergeant le r‚seau veilleront, avec l'aide des mod‚rateurs, … exclure toute personne abusant des codes ANSI dans une conf‚rence. Par d‚duction de la rŠgle pr‚c‚dente, tous les caractŠres ASCII VISIBLES sont accept‚s dans les conf‚rences SparkNet. (Codes 32 … 255) III.11 STRUCTURE DES MESSAGES ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Les utilisateurs ‚crivant en conf‚rence devront veiller … mod‚rer leurs entˆtes de d‚but de messages, ainsi que leurs signatures, qui ne devront pas prendre plus de 2 lignes chacune. Dans un but purement pratique, nous tenons … souligner que sur beaucoup de reader off-line, il est particuliŠrement fastidieux de quoter des lignes dont le nombre de caractŠres est sup‚rieur … 72. Vous pouvez donc, si vous le d‚sirez, ‚viter cette contraite aux personnes qui vous r‚pondent, en ‚crivant vos phrases dans cette limite de 72 colones. Dans la mˆme optique, vous noterez que certains programment gŠre ‚galement de maniŠre assez exotique les alin‚as et les tabulations en d‚but de ligne. Le problŠme n'apparait plus quand vous ‚crivez dŠs la colonne 0. Le signe officiel de quotage, qui devra ˆtre utilis‚ … l'exeption de tout autre, est le ">" et ceci pour assurer une parfaite compatibilit‚ entre les diff‚rents readers off-line. Il est ‚galement demand‚ d'utiliser le "Quotage" avec mod‚ration. On ‚vitera ainsi de Quoter tout un message avant d'y r‚pondre, mais plut“t les phrases importantes. III.12 VOTE & REFERENDUM (POUR SYSOPS UNIQUEMENT) ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Lorsqu'un vote ou referendum est engag‚, tous les sysops inscrits en NodeList au Vendredi qui pr‚cŠde imm‚diatement le d‚but de vote sont tenu de se prononcer. Les votes Blancs ou Nuls sont consid‚r‚s comme non exprim‚s. Les modalit‚s et les dur‚es de vote sont fix‚es par le comit‚ de pilotage mais ne peuvent jamais ˆtre inf‚rieures … 15 jours et sup‚rieures … 45 jours. Les votes sont toujours exprim‚s par NETMAIL envoy‚ en CRASH ou ROUTED … destination du Node Administratif 74:74/5. Les votes sont valides uniquement si le NETMAIL est re‡u … compter du jour de d‚but de vote … 0H00 CET-1 jusqu'au dernier jour 23H59 CET-1. Un vote exprim‚ ne peux plus ˆtre annul‚ ou modifi‚. Les r‚sultats des votes sont publi‚s par le ZC et sont automati- quement valid‚s si aucune r‚clamation n'est produite sous huits jours. IV. PROCEDURE DE MODIFICATION NODELIST & POINTLIST ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ La maintenance des Nodelist et PointList est trŠs importante pour le bon fonctionnement du r‚seau. Les mises … jours sont effectu‚es tous les vendredi soir … 21H00 CET-1. Les demandes de modifications doivent parvenir au nodes administratifs assurant la gestion avant le Vendredi 19H00 CET-1. IV.1 MODIFICATION NODELIST ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Pour la modification (ajout ou suppression) de nodes tous les NC devront proc‚der comme suit : Envoyer un NetMail … NodeMgr, au 74:74/2 et faire un FILE ATTACH d'un fichier texte qui contient la PORTION COMPLETE de NODELIST. Le nom du fichier est normalis‚ comme suit: Pour les Hosts: Z[nønet][nønode].[nøjour_derniŠre_nodelist + 7] Pour les RC : Z74-R[nøregion].[nøjour_derniŠre_nodelist + 7] IV.2 MODIFICATION POINTLIST ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ- Pour la modification (ajout ou supression) de points tous les nodes devront proc‚der comme suit: Envoyer un NetMail … PntMgr, au 74:74/3 et faire un FILE ATTACH d'un fichier texte qui contient la PORTION COMPLETE de POINTLIST. Le nom fu fichier est normalis‚ comme suit: P[nønet].[nønode] V. MAINTENANCE DES CONFERENCES ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ La conf‚rence SK_CONFS est d‚di‚e aux discussions sur les conf‚rences du r‚seau SPARKNET : Cr‚ation, Suppression, etc... Chaque conf‚rence du r‚seau est identifi‚e par son nom et son num‚ro officiel et doit disposer d'un animateur-Moderateur. Il est formellement interdit d'inscrire localement une conf‚rence pr‚fix‚e SK_ comme appartement au r‚seau SPARKNET avant l'annonce officielle en conf‚rence SK_NEWS & SK_ADMIN, SK_CONFS. V.1 LES MODERATEURS ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Il n'y a pas de limite d'ƒge pour devenir mod‚rateur, sauf pour la conf‚rence SK_ADULTE o— le mod‚rateur devra ˆtre ƒg‚ de 21 ans au minimum. Tout mod‚rateur d'une conference est astreint aux formalit‚s suivantes: - Il doit disposer d'un mailer - Il doit ˆtre identifier en NodeList ou en PointList - Il doit etablir les rŠgles sp‚cifiques de la conf‚rence dont il a la charge et les transmettre au Node Administratif 74:74/4 sous la forme d' un fichier normalis‚ sous le nom SK_###.REG ou ### represente le numero officiel de la conf‚rence. - Contr“ler le sujet des messages transitant en conf‚rence - Intervenir dŠs que possible ‚nergiquement pour enrayer une pol‚mique ou un thread priv‚ prolong‚. - Utiliser pour la mod‚ration le NETMAIL plutot que la conf‚rence - Et surtout animer sa conf‚rence. V.2 CREATION & SUPPRESSION DES CONFERENCES ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ La cr‚ation & la suppresion d'une conf‚rence propos‚e publiquement en conf‚rence SK_CONFS est soumis … la proc‚dure indiqu‚e dans le fichier SK_VOTE.TXT. Une fois la proc‚dure de vote termin‚e, le comit‚ de pilotage valide ou invalide l'action en cours (cr‚ation ou suppression). La d‚cision du comit‚ de pilotage est finale. V.3 MODERATION & SIGNATURE ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Lorsqu'un mod‚rateur use de sa fonction au sein de sa conf‚rence, il veillera … apposer … la fin de son message, la signature sous la forme suivante: Ú Nom Pr‚nom ¿ À Mod‚rateur SK_CONF Ù (Codes ASCII 218 191 192 217 ) Les utilisateurs (non-mod‚rateurs) ne devront PAS signer de cette maniŠre. Il doit transmettre son message de mod‚ration *EN PRIORITE* par NETMAIL avec copie au Node Administratif 74:74/4. --> Le Node Administratif transmet imm‚diatement le message de mod‚ration au SysOp h‚bergeant le user concern‚. Le SysOp destinataire doit mettre en place le plus rapidement possible les moyens pour repondre … la demande du mod‚rateur sous peine de suspension ou d'exclusion. --> L'usage d'un message de mod‚ration en conf‚rence publique doit ˆtre utiliser en dernier recours. Le mod‚rateur peut demander la suspension d'acc‚s provisoire ou d‚finitive. Dans ce dernier cas le comit‚ de pilotage doit valider cette exclusion. --> Lorsqu'une suspension ou exclusion est activ‚e pour une conf‚rence la sanction est propag‚e automatiquement sur toutes les autres conf‚rences du r‚seau SPARKNET. V.4 REGLES SPECIFIQUES DES CONFERENCES ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Les r‚gles ‚tablies par chaque mod‚rateur sont post‚es tous les 5 de chaque mois dans leurs conf‚rences respectives. Les modifications ‚ventuelle doivent parvenir au Node Administratif 74:74/4 avant le 28 de chaque mois. V.5 REGLES COMMUNES A L'ENSEMBLE DES CONFERENCES ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ En plus des informations indiqu‚es en section III.3 & V.4 les rŠgles suivantes s'appliquent par d‚faut … toutes les conf‚rences: - Limiter dans le temps les ‚changes priv‚s entre deux users. - Ne jamais tenter de mod‚rer une conf‚rence si vous n'ˆtes pas le mod‚rateur officiel (Utiliser plutot le NETMAIL en informant si possible le mod‚rateur) - Utiliser de pr‚f‚rence la conf‚rence correspondant le plus au sujet des discussions en cours, mˆme si le message d' origine est post‚ dans une autre conf‚rence. N'hesitez pas … r‚pondre … un message dans une autre conf‚rence mieux adapt‚e lorsque le sujet d‚rive. - Essayer dans la mesure du possible de changer les sujets des messages lorsque vous utiliser l'option REPLY pour r‚pondre … un message d'un autre utilisateur et que vous d‚sirez changer de sujet. - Utiliser les codes smiles, pour indiquer … votre interlocuteur que vous plaisanter ou que vous ˆtes s‚rieux ou autres et ceux afin d'‚viter toutes discussions ou toutes pol‚miques inutiles bas‚es sur un malentendu. - Dans la mesure du possible, ‚viter toutes discussions Politiques, R‚ligieuses ou Militaires. La qualit‚ des messages et l'image de marque du r‚seau d‚pend essentiellement du respect de ces rŠgles. Merci de les observer et de les faire respecter aussi souvent que possbile. ---/FIN/---