Sommaire

Du bon usage de...

Usenet

Le Brevet de Bon Citoyen d'Usenet
(traduction du GNKSA)

  1. Préambule
  2. Notes du traducteur
  3. Traduction de "The Good Net-Keeping Seal of Approval for Usenet Software" (GNKSA).

1 - Préambule

Le présent document contient la traduction française de la version 2.08 en date du 4 octobre 1999 du document intitulé "The Good Net-Keeping Seal of Approval" de Jeroen Scheerder.

Ce document, diffusé pour la première fois en 1995, est destiné à inventorier les fonctionnalités que tout logiciel de news est supposé posséder pour pouvoir être considéré comme un "bon" logiciel. Jeroen Scheerder, à la suite de Ron Newman, auteur de la première version, lance dans ce texte un appel à volontaires en vue de former un comité dont le rôle sera d'évaluer les logiciels de news et de leur attribuer ou non un brevet de bonne conduite (le fameux GNKSA ou BBCU en français).

L'attention du lecteur est attirée sur le fait que ce qu'expose l'auteur dans la première partie de son texte posait déjà de sérieux problèmes au début de l'année 1995, que ces problèmes sont encore plus d'actualité aujourd'hui et qu'ils seront incontournables demain. Si la communauté Usenet veut conserver une quelconque utilité à cet outil formidable de communication qu'est Usenet il est grand temps qu'elle réagisse.

Le traducteur se permet donc d'insister plus particulièrement sur l'importance et l'actualité du travail appelé par ce document et, en écho au souhait des auteurs originaux, appelle également de tous ses voeux la création d'un comité pour l'évaluation des logiciels en langue française.

Sur ce, bonne lecture !

2 - Notes du traducteur

Le traducteur attire l'attention du lecteur sur les points suivants :

  1. S'agissant d'une traduction réalisée par un non professionnel, et donc multipliant les risques d'erreurs de traduction, le texte traduit est de la seule responsabilité du traducteur et non de l'auteur. Les erreurs commises dans cette dernière doivent donc être signalées uniquement au traducteur et non pas à l'auteur du texte original. Toute réaction envoyée à l'auteur du texte original ne doit lui être transmise qu'après avoir pris connaissance du texte non traduit et non pas seulement de la traduction. Ou en d'autres termes, ne faites pas des remarques à l'auteur alors que l'origine de cette remarque proviendrait d'une erreur de traduction...
  2. Dans le texte traduit les conventions suivantes ont été suivies :
    '[ ]'
    Tout texte entre crochets est un ajout fait par le traducteur, soit parce qu'il a fallu proposer une terminologie française aux termes originaux, soit parce que le traducteur a jugé qu'une précision devait être apportée (cas rares).
    '( )'
    Pour éviter une incompréhension de termes généralement admis dans la communauté Usenet, les termes anglais accompagnent souvent leur traduction française. Ces termes anglais sont alors mis entre parenthèses. Exemple: (cancel), (Followup), etc... De cette manière, le texte est compréhensible par la majorité des personnes (anciens et nouveaux sur Usenet).
  3. Certains termes n'ont pas été traduits parce que le traducteur n'a pas trouvé de termes équivalents dans la langue française, c'est le cas de "cross-post" et "multi-post".
  4. Les termes suivants sont souvent employés, un petit mot d'explication sur chacun d'eux permettra d'éviter les contre-sens :
    • "le logiciel" signifie n'importe quel logiciel dont le rôle est de permettre à l'utilisateur de lire et/ou d'écrire et/ou d'envoyer des articles Usenet.
    • "champ" et "en-tête" sont interchangeables et se réfère le plus souvent au contenu d'un des champs (en-tête ou header en anglais) d'en-têtes d'un article.
  5. Les en-têtes de l'article original diffusé par Jeroen Scheerder ont été conservés (voir début de la traduction).
  6. La mise en pages d'origine a été autant que possible conservée : numérotation, sauts de paragraphes, etc...

3 - Traduction de "The Good Net-Keeping Seal of Approval for Usenet Software" 

From: Jeroen Scheerder 
Newsgroups: news.software.readers,comp.os.msdos.mail-news,
 comp.os.os2.mail-news,comp.sys.mac.comm,comp.os.ms-windows.apps.comm,
 comp.os.ms-windows.apps.winsock.news,alt.usenet.offline-reader,
 alt.answers,comp.answers,news.answers
Subject: Good Net-Keeping Seal of Approval 2.0 (GNKSA 2.0) for Usenet
 Software
Approved: news-answers-request@MIT.EDU
Followup-To: news.software.readers
Summary: Guidelines for writers of Usenet reading and posting programs.
 If you follow these guidelines, you'll make your users and the rest
 of the Usenet community much happier.
X-Note: This is an updated and revised descendant of Ron Newman's GNKSA 1.2

Archive-name: usenet/software/good-netkeeping-seal
Posting-Frequency: monthly (first Sunday)
Last-modified: Oct 4 1999
Version: 2.08
URL: http://www.xs4all.nl/%7Ejs/gnksa/
Maintainer: Jeroen Scheerder

BBCU * Le Brevet de Bon Citoyen d'Usenet

L'impression générale est qu'Usenet devient plus "bruyant" au fur et à mesure que plus de personnes y ont accès. Il y a plus d'articles vides, plus d'en-têtes incorrects, plus de réponses où un simple "moi aussi" accompagne une grande quantité de texte repris, plus de réponses dans des groupes inappropriés, plus de textes repris attribués au mauvais auteur, plus de réponses publiques qui auraient vraiment dû être envoyées par courrier électronique, plus de cross-posts et de multi-posts abusifs, plus d'articles encodés d'une façon illisible ou mutilés d'une façon ou d'une autre.

Cette situation est souvent reprochée aux nouveaux utilisateurs eux-mêmes - qualifiés de débutants ignorants ("clueless newbies") - incapables de participer à Usenet parce qu'ils ne connaissent pas Unix, ou qu'ils utilisent une interface graphique mal conçue, ou qu'ils utilisent un lecteur hors-ligne, ou qu'ils utilisent un service commercial comme AOL ou Delphi.

Je crois que la majorité de cette irritation est mal ciblée. Les nouveaux utilisateurs ne sont pas vraiment si différents des vieux routiers. Ce qui est différent, c'est que la majorité des vieux routiers utilisent des logiciels relativement bien élevés, typiquement "rn" ou un de ses dérivés, alors que beaucoup de nouveaux venus utilisent "tin", "uqwk", "AOL" ou divers lecteurs de news pour PC. Malheureusement, ces programmes transgressent fréquemment les suppositions qui sont devenues naturelles pour les utilisateurs de logiciels bien élevés, comme :

  • L'utilisateur peut voir les en-têtes indispensables, y compris la liste des groupes dans laquelle l'article a été posté ("Newsgroups") et la liste des groupes dans laquelle il est demandé de répondre ("Followup-To").
  • L'utilisateur peut éditer tous les en-têtes en composant sa réponse.
  • Il y a une différence marquée entre une réponse publique ("followup") et une réponse par courrier électronique ("reply").
  • Les réponses préservent le sujet et les références présentes dans l'article original, à moins que l'utilisateur ne les modifie explicitement.
  • Les logiciels de news respectent les indications des champs "Followup-To:" et "Reply-To:".
  • Ce que l'utilisateur écrit est envoyé par le logiciel tel quel.

Les nouveaux logiciels devraient être des versions améliorées d'anciens programmes comme "rn". Au lieu de cela, bon nombre d'entre eux sont défectueux ou bancals en comparaison.

La communauté Usenet peut s'attaquer à ce problème en établissant un Brevet de Bon Citoyen d'Usenet (Good Net-Keeping Seal of Approval - GNKSA en anglais) aux logiciels de news. Ce brevet certifierait que le logiciel respecte certains standards minimaux, comme ceux listés ci-dessous.

Un groupe de volontaires testera tous les nouveaux logiciels de news pour déterminer s'ils satisfont aux conditions du Brevet, avec l'intention de poster périodiquement une liste de tous les logiciels testés dans news.software.readers, alt.usenet.offline-reader, et autres groupes appropriés [fr.usenet.logiciels pour la hiérarchie francophone - NdT]. Ces articles périodiques listeront les logiciels conformes comme les logiciels non-conformes ; pour les logiciels non-conformes, il mentionnera la liste de toutes les transgressions des standards. Cela est fait dans l'espoir d'encourager les auteurs de logiciels non-conformes à amener leurs programmes au niveau des standards du Brevet de Bon Citoyen.

Voici les standards proposés qu'un logiciel de news d'Usenet devrait respecter pour mériter le Brevet de Bon Citoyen :

  1. Afficher tous les en-têtes essentiels
  2. Fournir des commandes claires et distinctes pour envoyer un nouvel article et pour répondre publiquement ou par courrier électronique
  3. Fournir une fonctionnalité de cross-post
  4. Permettre aux utilisateurs de modifier les en-têtes essentiels
  5. S'assurer que les réponses publiques et par courrier électronique contiennent un champ "Subject:" correct
  6. Diriger les réponses publiques sur les bons groupes
  7. S'assurer que les réponses publiques contiennent un champ "References:" valide
  8. Diriger les réponses par courrier électronique à la bonne adresse
  9. Permettre à l'utilisateur de changer d'avis concernant le choix de répondre publiquement ou par courrier électronique
  10. Permettre de reprendre et d'attribuer correctement les textes
  11. Fournir un champ "Subject:" spécifié par l'utilisateur
  12. Fournir un champ "From:" valide
  13. Permettre aux utilisateurs d'annuler et de remplacer (supersede) leur propres articles (et _pas_ ceux des autres !)
  14. Essayer de respecter la limite conventionnelle de 80 caractères par ligne
  15. Utiliser un séparateur de signature correct, et ne pas utiliser de signatures excessives
  16. Essayer d'éviter les erreurs les plus fréquentes de l'utilisateur
  17. Poster des articles lisibles par l'homme, à moins que le contraire ne lui soit spécifié
  18. Fournir une protection à l'utilisateur
  19. Se comporter correctement avec les serveurs, laisser de la place aux autres

Ces conditions sont décrites plus en détail ci-dessous. Dans l'esprit de la RFC 1123 et de la proposition d'Henry Spencer "son of RFC 1036", j'ai mis en lettres capitales les mots "DOIT", "NE DOIT PAS", et "NE PAS FAIRE" pour indiquer des conditions absolument requises, et le mot "DEVRAIT" pour des choses qui sont simplement de Vraiment Très Bonnes Idées.

1) Afficher tous les en-têtes essentiels

Quand un article est affiché, le logiciel DOIT par défaut montrer à l'utilisateur certaines des informations qui se trouvent dans les en-têtes de l'article. Cette information n'a pas nécessairement à être affichée dans le format de la RFC 1036, mais elle DOIT être présentée à l'utilisateur sous une forme ou une autre.

  1. L'auteur de l'article (champ "From:" des en-têtes)
  2. Le sujet de l'article. Au moins les 70 premiers caractères suivant la chaîne de caractères "Subject: " DOIVENT être affichés.
  3. La liste des groupes dans lesquels l'article a été posté. Cette liste DOIT être présentée en entier, jamais tronquée. Cette liste n'a pas besoin d'être affichée si elle ne comprend qu'un seul élément, pourvu que le logiciel affiche le nom du groupe que l'utilisateur est en train de lire.
  4. La liste des groupes dans laquelle il faut répondre (champ "Followup-To:"), si elle est différente de la liste des groupes. Cette liste DOIT être présentée en entier, jamais tronquée.
  5. L'adresse de réponse de l'article (champ "Reply-To:"), si elle est différente de l'adresse de l'auteur (champ "From:").

Si les informations requises ne peuvent pas tenir intégralement à l'écran, le logiciel PEUT n'afficher que la partie initiale de l'information, pourvu qu'il offre à l'utilisateur une barre de défilement ou d'autres moyens équivalents pour visualiser le reste.

Le logiciel PEUT autoriser l'utilisateur à le reconfigurer pour supprimer l'affichage de ces informations, mais si l'utilisateur ne l'a pas fait, toutes les informations requises DOIVENT être affichées.

Raison : L'utilisateur devrait pouvoir voir, sans avoir à faire d'effort particulier pour cela, qui a envoyé l'article qu'il est en train de lire, comment y répondre par courrier électronique, dans quels groupes de discussion il a été posté, et si l'auteur de l'article veut limiter ou rediriger la suite de la discussion.

2) Fournir des commandes claires et distinctes pour envoyer un nouvel article et pour répondre publiquement ou par courrier électronique

Le logiciel DOIT fournir des commandes séparées et clairement distinctes pour effectuer chacune des tâches suivantes :

  1. Poster un nouvel article, sans lien avec un autre déjà existant, dont le sujet doit être donné par l'utilisateur, et qui a un en-tête "References:" vide ou absent.
  2. Poster une réponse publique (followup), avec des en-têtes "Subject:", "Newsgroups:", et "References:" déduits correctement de l'article original (voir les sections 5, 6 et 7 ci-dessous).
  3. Répondre par courrier électronique, avec des en-têtes "Subject:" and "To:" déduits correctement de l'article original (voir les sections 5 et 8 ci-dessous).

Les logiciels qui utilisent l'anglais sont fortement encouragés à inclure les phrases "Post to newsgroup", "Followup to newsgroup", et "Reply by e-mail" (ou "Reply to sender" ou "Reply to author") dans leurs menus, leur aide en ligne et leur documentation papier. Ils DEVRAIENT éviter d'utiliser d'autres expressions comme "Send" ou "Respond" dont la signification est ambiguë pour l'utilisateur. Un utilisateur ordinaire, non habitué DEVRAIT être capable de choisir la bonne commande facilement.

[Les logiciels qui utilisent le français sont fortement encouragés à inclure les phrases "Poster un article", "Répondre en public", et "Répondre par courrier électronique" (ou "Répondre en messagerie") dans leurs menus, leur aide en ligne et leur documentation papier. Ils DEVRAIENT éviter d'utiliser d'autres expressions comme "Envoyer" ou "Répondre" dont la signification est ambiguë pour l'utilisateur. Un utilisateur ordinaire, non habitué DEVRAIT être capable de choisir la bonne commande facilement.]

Raison : Les utilisateurs qui répondent en public quand ils devraient répondre par courrier électronique, ou vice versa, semblent former un problème endémique. Ils utilisent presque toujours des logiciels qui ne montrent pas clairement la différence, ou ne fournissent même pas les deux commandes.

3) Fournir une fonctionnalité de cross-post

Lorsqu'il crée un nouvel article ou une réponse publique, l'utilisateur DOIT être autorisé à spécifier plusieurs groupes, et le logiciel DOIT cross-poster (et pas multi-poster) dans ces groupes si plus d'un groupe a été spécifié.

Les logiciels DEVRAIENT empêcher l'utilisateur d'effectuer des cross-posts excessifs, ou au moins l'en avertir. Si l'utilisateur poste dans in grand nombre de groupes, le logiciel DEVRAIT le forcer ou lui suggérer fortement de positionner un champ d'en-tête "Followup-To:". Un tel champ doit être sujet à des restrictions qui sont au moins aussi strictes que celles imposées à la liste des groupes destinataires (champ "Newsgroups:").

Raison : Le cross-post est une fonctionnalité importante d'Usenet. Si le logiciel ne peut pas cross-poster, ses utilisateurs multi-posteront à la place. Toutefois, il faut essayer raisonnablement de protéger l'utilisateur contre des cross-posts excessifs (généralement réalisés par inadvertance, et si ce n'est pas le cas, souvent considérés comme des abus du réseau) qui ne mènent qu'à des annulations et des guerres d'enflammage.

4) Permettre aux utilisateurs de modifier les en-têtes essentiels

Lorsqu'il crée un nouvel article ou une réponse publique, le logiciel DOIT autoriser l'utilisateur à modifier le sujet (champ "Subject:"), la liste des groupes destinataires (champ "Newsgroups:"), la liste des groupes où poursuivre la discussion (champ "Followup-To:") et l'adresse de réponse par courrier électronique (champ "Reply-To:"). L'utilisateur DOIT pouvoir les modifier à n'importe quel moment durant la composition de l'article ; le logiciel NE DOIT PAS le forcer à les spécifier uniquement avant, ou après la rédaction du corps de l'article.

Le logiciel DOIT permettre à l'utilisateur de spécifier un nouveau champ "Subject:" d'au moins 70 caractères, sans compter la chaîne "Subject: " elle-même. Il est préférable de ne pas imposer de limite du tout, à part la limite générale de 998 caractères par lignes d'en-tête spécifiée dans le document "son-of-RFC-1036" (voir la section 7).

Le logiciel DOIT permettre à l'utilisateur de spécifier "Followup-To: poster", ce qui indique aux lecteurs que l'utilisateur préfère recevoir des réponses par courrier électronique plutôt que des réponses publiques.

Ceci ne signifie pas que le logiciel doit présenter à l'utilisateur des en-têtes bruts au format de la RFC 1036, ou que les en-têtes et le corps de l'article doivent former un bloc indivisible de texte éditable. Une interface utilisateur graphique qui présente chacun de ces en-têtes comme un champ éditable dans un formulaire satisfera aux conditions.

Raison : Les sujets de discussion évoluent au fur et à mesure du débat, et les utilisateurs doivent pouvoir changer le sujet pour refléter cette évolution. D'une façon similaire, un utilisateur peut déterminer que la discussion ne concerne plus certains des groupes où elle a commencé, ou qu'elle doit se poursuivre ailleurs. Le logiciel ne doit pas empêcher l'utilisateur de tirer les conséquences de son jugement, y compris durant la composition de l'article de réponse. Il n'est pas acceptable d'entendre des utilisateurs doivent répondre à la demande "Redirigez les réponses de manière appropriée, s'il vous plaît" par "Je ne peux pas, mon logiciel ne me le permet pas".

5) S'assurer que les réponses publiques et par courrier électronique contiennent un champ "Subject:" correct

Lorsqu'il crée une réponse publique ou par courrier électronique, le logiciel DOIT créer un champ "Subject:" initial qui :

  1. préfixe le sujet par les quatre caractères "Re: " si et seulement si "Re :" n'est pas déjà présent. Notez que cette chaîne de caractères comporte un "R" majuscule, un "e" minuscule, et un espace terminal. NE PAS préfixer le sujet par des préfixes non-standard comme "Re^2: ".
  2. préserve le sujet *intégral* de l'article original. NE PAS le tronquer à 20, 25 ou même 80 caractères. NE PAS ajouter d'espaces ou d'autres caractères à la fin. NE PAS modifier la casse des caractères du sujet original ; en particulier, NE PAS mettre le sujet entièrement en majuscules ou en minuscules.

(L'utilisateur peut bien sûr changer le sujet ultérieurement ; voir la section 4 ci-dessus.)

Exception : Le logiciel PEUT essayer de compenser les défauts d'autres logiciels en remplaçant les préfixes non-standard (tels que "Re^2: ", "Re(2): ", "Re:" (sans espace), "RE: ", "re: " , or "Re: Re: ") par le préfixe standard "Re: ".

Raison : Ces choses peuvent sembler évidentes, mais de nombreux auteurs de logiciels de news ne semblent pas comprendre les sections de la RFC 1036 qui traitent de ce sujet. Les champs "Subject: " tronqués, en particulier quand des caractères non-ASCII sont supprimés, sont une source d'ennui majeure pour les utilisateurs et peuvent rendre le suivi des fils de discussions difficile ou impossible.

6) Diriger les réponses publiques sur les bons groupes

Lorsqu'il crée une réponse publique, le logiciel DOIT créer un champ "Newsgroups:" dont la valeur initiale est initialisée au contenu du champ "Followup-To:" de l'article original, s'il y en avait un, et sinon au contenu du champ "Newsgroups:".
(L'utilisateur peut bien sûr changer ce champ ultérieurement ; voir la section 4 ci-dessus.)

Si le champ "Followup-To:" de l'article original contient la valeur "poster", le logiciel DOIT avertir l'utilisateur que l'auteur original a demandé une réponse par courrier électronique, et générer par défaut une réponse par courrier électronique.

Raison : Il s'agit du respect de base de la RFC 1036. Les logiciels qui ne s'y conforment pas font passer leurs utilisateurs au mieux pour des imbéciles ou des incompétents, et au pire pour des gens volontairement irrespectueux des attentes des autres utilisateurs d'Usenet.

7) S'assurer que les réponses publiques contiennent un champ "References:" valide

Lorsqu'il crée une réponse publique, le logiciel DOIT créer un champ "References:" qui contient comme dernier élément l'identificateur de message (Message-ID) de l'article original. Un identificateur de message NE DOIT jamais être tronqué.

Le logiciel DOIT inclure au moins trois identificateurs de message supplémentaires de l'en-tête "References:" de l'article original, s'ils existent. Essayez de rester aussi proches que possible de l'esprit du document "Son of RFC 1036", qui stipule :

« Les logiciels qui génèrent des réponses publiques NE DEVRAIENT pas raccourcir le champ "References:". S'il est absolument nécessaire de raccourcir ce champ, en dernier ressort, le logiciel PEUT le faire en effaçant certains des identificateurs de message (Message-ID). Cependant, il NE DOIT effacer ni le premier identificateur, ni les trois derniers identificateurs (en comptant celui de l'article auquel il est répondu), ni les identificateurs mentionnés dans le corps de la réponse. »

Cependant, ce document dit aussi :

« S'il est absolument nécessaire à un logiciel d'imposer une limite à la taille des lignes des en-têtes, du corps du message ou des lignes logiques d'en-têtes, cette limite sera d'au moins 1000 octets, en comptant les délimiteurs de fin de ligne. »

Aussi, ayez à l'esprit que les logiciels de transport de news ne sont pas forcément capables de gérer des lignes de n'importe quelle longueur. De plus, gardez à l'esprit que certains transporteurs de news bloquent sur les champs "References:" continués sur plusieurs lignes.

Donc, gardez autant d'identificateurs de message qu'il peut en tenir sur une ligne commençant par "References: " avec une longueur maximale de 998 caractères. (Un délimiteur de fin de ligne est constitué de deux octets.)

Exception : Les identificateurs de message endommagés (tronqués) NE DEVRAIENT PAS être inclus. Pas plus que ne devraient l'être de faux identificateurs de messages, qui ont été insérés d'une façon ou d'une autre (peut-être par une erreur de l'utilisateur) mais qui n'appartiennent pas au fil.

Raison : Les lecteurs capables de classer les discussions par fils se basent sur le champ "References:" pour assurer cette fonctionnalité. Cela aussi constitue le respect de base de la RFC 1036. Soyez aussi complets que la limite de longueur de ligne le permet, mais ne propagez pas les erreurs.

8) Diriger les réponses par courrier électronique à la bonne adresse

Lorsqu'il crée une réponse par courrier électronique, le logiciel DOIT créer un champ "To:" dont la valeur initiale est initialisée au contenu du champ "Reply-To:" de l'article original, s'il y en avait un, et sinon au contenu du champ "From:". (L'utilisateur peut bien sûr changer ce champ ultérieurement ; voir la section 4 ci-dessus.)

Raison : Voir la section 6 ci-dessus.

9) Permettre à l'utilisateur de changer d'avis concernant le choix de répondre publiquement ou par courrier électronique

Pour toute réponse publique ou par courrier électronique, le logiciel DEVRAIT fournir à l'utilisateur la possibilité de changer d'avis concernant le choix du type de réponse, et peut lui permettre de faire les deux à la fois.

Si le logiciel permet d'envoyer la même réponse à la fois publiquement et par courrier électronique, cette option NE DOIT PAS constituer le comportement par défaut, ni dans la configuration d'origine ni par un changement de cette configuration par l'utilisateur. De plus, quand une réponse est envoyée des deux façons, le corps du message envoyé par courrier électronique DEVRAIT être précédé d'une ligne indiquant clairement que le message est une copie par courrier électronique d'un article envoyé sur Usenet.

Raison : Les gens digressent en écrivant, et peuvent se retrouver à envoyer publiquement un message qui aurait été plus approprié pour une communication privée, ou à envoyer par courrier électronique un message qu'il aurait mieux valu soumettre à l'assistance générale. Les réponses non sollicitées par courrier électronique sont très peu appréciées par de nombreux utilisateurs (s'ils avaient voulu des réponses par courrier électronique, ils auraient pu, auraient dû, et le lecteur peut supposer qu'ils auraient effectivement demandé que cela soit le cas).

10) Permettre de reprendre et d'attribuer correctement les textes

Quand l'utilisateur cherche à répondre publiquement ou par courrier électronique, le logiciel DOIT fournir une méthode pour inclure du texte cité de l'article original). Ce texte repris DOIT être clairement identifié d'une manière ou d'une autre, soit en l'indentant, soit en préfixant chaque ligne d'un ou plusieurs caractères identifiables. Le préfixe en question DEVRAIT être ">", suivi optionnellement d'un espace (c'est-à-dire "> ").

Remarque : avec ">", le niveau de citations se reflète clairement dans le nombre de caractères ">" au début de la ligne. Toutefois, un espace entre le préfixe et le texte cité améliore la lisibilité, aussi une bonne pratique pour les lecteurs de nouvelle consisterait donc à utiliser "> " comme préfixe pour le texte nouvellement cité et ">" pour du texte cité plusieurs fois.

Le texte repris NE DEVRAIT PAS contenir la signature de l'article originale, sauf demande explicite de l'utilisateur (à condition évidemment que la signature puisse être déterminée, c'est-à-dire si elle est clairement séparée du reste du texte par le délimiteur de signature standard). Voir aussi la section 15 ci-dessous.

Comme contrepartie directe de cette exigence, le logiciel DEVRAIT offrir à l'utilisateur un moyen de sélectionner exactement à quelle partie d'un article d'Usenet il souhaite répondre, et citer uniquement cette partie. (Un cas particulier est quand l'utilisateur souhaite réagir à ce qui se trouve dans une signature.)

S'il s'agit d'une réponse publique (par opposition à une réponse par courrier électronique), le texte cité DOIT être précédé d'une "ligne d'attribution" identifiant l'auteur du texte cité. (L'utilisateur peut décider d'effacer cette ligne ou de configurer le logiciel pour ne plus l'ajouter, mais elle DOIT être présente par défaut.)

Raison : La possibilité de reprendre du texte facilement est essentielle pour les utilisateurs qui souhaitent fournir un contexte à leurs réponses. Les logiciels qui fournissent de lignes d'attribution sans la possibilité de citer du texte, ou qui ne sont pas capables de distinguer clairement le texte repris du texte original, sont une cause majeure de "Je n'ai jamais dit cela !". Par convention, les lignes reprises commencent par ">", et de nombreux logiciels dépendent de cela pour distinguer le texte repris des lignes originales, dans un but de présentation. Les utilisateurs peuvent occasionnellement (voire même souvent) être inattentifs ou distraits et négliger d'enlever le texte repris en trop ; la signature est typiquement ce genre de texte excédentaire. En général, faciliter des citations correctes - par exemple en ne citant qu'une partie indiquée par l'utilisateur - est un domaine dans lequel le logiciel peut aider substantiellement les utilisateurs à créer de meilleurs articles.

11) Fournir un champ "Subject:" spécifié par l'utilisateur

Lorsqu'il crée un nouvel article, le logiciel DOIT exiger de l'utilisateur qu'il fournisse un sujet non vide. Il NE DOIT PAS poster un article sans champ "Subject:" ou avec un champ "Subject:" vide. Il NE DOIT PAS ajouter de lui-même un sujet par défaut (comme "Subject: pas de sujet") si l'utilisateur n'en a pas spécifié un. Il DOIT autoriser l'utilisateur à modifier le sujet à tout moment pendant l'édition du corps de l'article (voir la section 4 ci-dessus).

Raison : Un article sans sujet ne fournit aucune indication pour décider de le lire ou non. Pour cette raison, il sera probablement ignoré par beaucoup de personnes, et ce n'est pas rendre service aux utilisateurs que d'autoriser l'envoi de tels articles ; alors que d'autres lecteurs pourraient le lire pour s'apercevoir qu'ils n'auraient pas dû s'en soucier et que cet article s'avère n'être d'aucun intérêt.

12) Fournir un champ "From:" valide

Lorsqu'il crée un nouvel article ou une réponse publique, le logiciel DOIT initialiser le champ "From:" avec une adresse email syntaxiquement correcte, ce qui inclut un nom de domaine pleinement qualifié (fully-qualified domain name - FQDN).

Cette exigence doit être remplie, que le logiciel

  1. crée le champ "From:" quand l'utilisateur crée l'article, ou
  2. ajoute le champ "From:" automatiquement quand l'utilisateur a terminé d'éditer l'article et lui demande de l'envoyer.

Si le logiciel permet à l'utilisateur de modifier le champ "From:", il DEVRAIT vérifier que l'utilisateur a fourni une adresse syntaxiquement correcte.

Si le logiciel est incapable de créer une telle adresse - peut-être parce qu'il est paramétré incorrectement, ou parce que certains paramètres sont indisponibles à ce moment-là - il NE DOIT PAS permettre du tout l'envoi de l'article, à moins qu'il ne puisse obtenir de l'utilisateur une adresse dont la syntaxe est correcte.

Si cela est réalisable, le logiciel DEVRAIT essayer de garantir que l'adresse en question appartient bien à la personne qui utilise le logiciel, et qu'elle est capable de recevoir du courrier.

Raison : Les systèmes de transport de courrier et de news, ainsi que les logiciels des utilisateurs, les passerelles et les logiciels de traitement peuvent se bloquer en rencontrant des en-têtes syntaxiquement incorrects. Les adresses email invalides rendent les réponses par courrier électronique impossibles ; voir le document de Greg Byshank "Help! I've been spammed!" pour une excellent discussion des points concernés. [En français, voir la FAQ de Stéphane Marchau "Les adresses "antispam"". - NdT]

13) Permettre aux utilisateurs d'annuler et de remplacer (supersede) leur propres articles (et _pas_ ceux des autres !)

Tout logiciel qui poste des articles DEVRAIT fournir une commande à l'utilisateur pour annuler ses propres articles. Il DEVRAIT aussi fournir la possibilité de remplacer (supersede) les articles de l'utilisateur. Le logiciel DOIT garantir que l'utilisateur ne peut pas annuler ou remplacer les articles d'autres personnes, autant que possible.

Remarque : étant donné qu'une authentification totalement fiable peut être impossible à obtenir, le mieux que le logiciel puisse faire est de faire un effort pour déterminer s'il est légitime ou non d'annuler ou de remplacer, par exemple en examinant sa configuration et en la comparant contre le ou les en-têtes adaptés de l'article concerné.

Si le logiciel utilise l'anglais, le texte de la commande d'annulation DEVRAIT inclure le mot "cancel", plutôt que des verbes non standard comme "delete". D'une manière similaire, dans un logiciel en anglais, le texte de la commande de remplacement DEVRAIT inclure le mot "supersede". [Si le logiciel utilise le français, le texte de la commande d'annulation DEVRAIT inclure le mot "annuler", plutôt que des verbes non standard comme "effacer". Il n'y a pas de terme français standard pour la commande de remplacement, donc le logiciel DEVRAIT indiquer un verbe explicite comme "remplacer" et rappeler en même temps le terme anglais de "supersede". - NdT]

Raison : Les gens font des erreurs et ont besoin de pouvoir les supprimer ou les corriger ; l'annulation et le remplacement existent pour de bonnes raisons. Toutefois, le logiciel ne devrait pas encourager ses utilisateurs à abuser de cette fonctionnalité, soit intentionnellement soit accidentellement, en envoyant des annulations ou des remplacements non autorisés ("sauvages") [c'est-à-dire portant sur des articles ne provenant pas de l'utilisateur - NdT]. La possibilité de remplacement est essentielle : à cause de la propagation des articles sur Usenet, parfois imprévisible, une annulation suivie d'un repostage peut donner des résultats très différents d'un remplacement. Les serveurs de nouvelles peuvent aussi avoir des politiques d'acceptation différentes pour les deux types d'articles.

14) Essayer de respecter la limite conventionnelle de 80 caractères par ligne

Tous les retours à la ligne affichés à l'utilisateur lorsqu'il rédige son article DEVRAIENT être toujours présents lorsque l'article est effectivement envoyé sur le réseau. Le logiciel NE DEVRAIT PAS montrer à l'utilisateur quatre lignes de 75 caractères tout en envoyant en fait une seule ligne de 300 caractères. Il ne devrait pas non plus montrer à l'utilisateur une série de lignes de 100 caractères tout en envoyant en fait alternativement des lignes de 80 et de 20 caractères.

C'est également une bonne idée d'avertir l'utilisateur si l'article qu'il se prépare à envoyer contient dans son corps des lignes de longueur supérieure à 80 caractères. Le logiciel NE DEVRAIT PAS empêcher l'envoi de l'article, mais DEVRAIT demander si l'utilisateur désire reformater l'article ou l'envoyer quand même.

Remarque : Occasionnellement, il y a de très bonnes raisons de poster des lignes plus longues (par exemple, quand on envoie du code source indenté qui risque d'être coupé si les lignes sont repliées, ou quand il y a besoin d'envoyer quelque chose "tel quel", non reformaté - non modifié et complètement intact). Pour cette raison, (re)formater ne peut pas être une exigence absolue (DOIT) : il ne peut être qu'un conseil (DEVRAIT).

Pour obtenir des articles lisibles, l'utilisateur DEVRAIT disposer de la possibilité de reformater des lignes trop longues de texte cité, tout en respectant les niveaux de citation - c'est-à-dire avoir la possibilité de corriger un mauvais formatage "hérité" de l'auteur précédent. Les caractères de tabulation DEVRAIENT également être remplacés par leur équivalent en espaces pour éviter les problèmes qui peuvent se produire quand un lecteur utilise une taille différente pour les tabulations.

Remarque : Etant donnée l'immense variété des styles de citation, le reformatage du texte cité peut être extrêmement dur, voire pratiquement impossible. On ne peut pas attendre d'un logiciel qu'il puisse traiter tous les cas de figure ; cependant, vu que la grande majorité des cas peuvent être traités relativement facilement, il n'est pas déraisonnable d'attendre des logiciels qu'ils puissent le faire s'ils veulent être bien équipés pour la tâche de composer des articles sur Usenet.

Si le logiciel utilise un éditeur de texte externe, l'éditeur par défaut DEVRAIT être conforme aux spécifications ci-dessus.

Raison : Les articles avec des lignes trop longues sont illisibles pour de nombreux utilisateurs. Les articles alternant des lignes de 80 et de 20 caractères ne valent pas mieux.

15) Utiliser un séparateur de signature correct, et ne pas utiliser de signatures excessives

Le logiciel DEVRAIT séparer une signature apposée aux messages envoyés du texte principal de l'article par une ligne contenant uniquement "-- " (deux tirets et un espace). Pour reprendre les termes du document "son of RFC 1036" :

« Si un auteur ou un logiciel appose une signature à un article, la signature DEVRAIT être précédée d'une ligne de séparation contenant (seulement) deux tirets (ASCII 45) suivis d'un blanc (ASCII 32). Les logiciels DEVRAIENT limiter la longueur des signatures, car un excès de bruit confinant à l'abus est commun si aucune restriction n'est imposée ; 4 lignes constituent une limite habituelle. »

Pour cette raison, le logiciel DOIT empêcher l'utilisateur d'utiliser des signatures de longueur excessive, ou au moins l'avertir pour éviter cela. Un standard largement accepté est la limite dite de McQuary : pas plus de 4 lignes, chacune de ces lignes ne faisant pas plus de 80 caractères.

Raison : Il est pénible, ou il peut être pénible pour beaucoup de personnes d'être confrontés de manière répétitive avec des signatures parfois trop longues. Il est important de pouvoir séparer clairement le texte principal et la signature, non seulement pour empêcher l'erreur possible d'une mauvaise interprétation de la signature, mais aussi pour permettre la suppression automatique des signatures pour ceux qui le souhaitent.

16) Essayer d'éviter les erreurs les plus fréquentes de l'utilisateur

  • Le logiciel DOIT avertir un utilisateur qui s'apprête à envoyer un article vide, et DEVRAIT l'en empêcher complètement.
  • Le logiciel DOIT avertir un utilisateur qui s'apprête à envoyer un article composé uniquement de texte cité, et DEVRAIT l'en empêcher complètement.
  • Le logiciel DOIT avertir sérieusement un utilisateur qui essaie d'envoyer le même article plusieurs fois, et DEVRAIT faire tout ce qu'il peut pour l'en empêcher complètement.
  • S'il envoie les articles de manière "asynchrone" (c'est-à-dire en renonçant à la connaissance de l'état d'avancement, du succès ou de l'échec en déléguant complètement la tâche à un processus séparé) il NE DEVRAIT PAS autoriser l'utilisateur à envoyer un article de nouveau une fois qu'il a lancé la commande finale d'envoi de l'article.
  • S'il envoie les articles de manière "synchrone", le logiciel a au moins une connaissance partielle de l'état d'avancement, et une connaissance complète du succès ou de l'échec de la tentative d'envoi de l'article. Dans ce cas, il DEVRAIT informer l'utilisateur que l'article est en train d'être envoyé pendant qu'il essaie de l'envoyer ; après la tentative, il DOIT informer l'utilisateur d'une manière non équivoque que l'envoi a réussi si c'est le cas, et qu'il a échoué sinon.

Note : Les logiciels de news "en ligne" envoient généralement (mais pas nécessairement) les articles de manière synchrone, tandis qu'un certain nombre de méthodes de lecture de news "hors ligne" (en particulier celles programmées pour un traitement par lots) envoient généralement les articles de manière asynchrone. Cependant, les logiciels de news hors ligne qui utilisent NNTP pour le transport des news envoient généralement les articles de manière synchrone, c'est-à-dire qu'ils sont en interaction directe avec le serveur de news, obtenant ainsi des résultats immédiats lors de l'envoi.

Raison : Les utilisateurs qui commettent ces erreurs ne le font pratiquement jamais volontairement. Ils sont généralement induits en erreur par de nouveaux logiciels qui ne leur sont pas familiers, et devraient bénéficier d'une protection élémentaire.

17) Poster des articles lisibles par l'homme, à moins que le contraire ne lui soit spécifié

Le logiciel DOIT ne poster par défaut que des articles Usenet lisibles. Autrement dit : il NE DOIT PAS encoder ou encrypter des articles, sauf dans le cas d'une demande explicite de l'utilisateur. Ainsi, il NE DOIT PAS même avoir la possibilité d'encoder ou d'encrypter par défaut. Quand un encodage ou un encryptage a été demandé, un retour d'information clair montrant qu'il est activé DOIT être fourni à l'utilisateur, de sorte qu'il est informé en permanence que son article ne sera pas posté tel qu'il a été composé. `La pire chose à NE PAS FAIRE consiste à combiner ces deux défauts en permettant un encodage par défaut sans prendre la peine d'avertir l'utilisateur au moment de l'envoi.

Note : Des occurrences fréquentes de ce type de mutilation du contenu non demandé par, et caché à l'utilisateur, sont les encodages en HTML, en MIME multipart et/ou en Base64, comme on les trouve dans certains lecteurs de news intégrés à des navigateurs Web, qu'il vaut mieux ne pas mentionner ici.

Raison : De nombreux utilisateurs peuvent ne pas être capables du tout de lire des articles encodés ou encryptés de certaines façons, ou seulement au prix d'efforts considérables : de tels articles risquent d'être largement ignorés. Faciliter l'envoi de messages mutilés ne rend service ni à l'utilisateur lui-même, ni à son auditoire. Gardez à l'esprit que tout le monde n'a pas le même paramétrage particulier (lecteur de news, configuration, système d'exploitation) que vous, et que les lecteurs ne devraient pas (et ne peuvent pas) être obligés de l'avoir pour pouvoir lire vos articles.

18) Fournir une protection à l'utilisateur

Le logiciel DEVRAIT permettre à l'utilisateur de se protéger en filtrant les articles qu'il ne veut vraiment pas lire. Ces possibilités de filtrage DEVRAIENT être suffisamment puissantes pour pouvoir ignorer les articles provenant de certaines personnes, à propos de certains sujets, et cross-postés d'une certaine façon.

Raison : Bien qu'il semble que le fait de ne pas avoir de filtres n'affecte que l'utilisateur, les utilisateurs ont tendance à être influencés dans leurs articles s'ils sont gênés de manière répétitive (systématique) par une certaine catégorie d'articles, et risquent d'annuler des articles, de réclamer des restrictions de postage ou de s'engager dans des guerres d'enflammage, toutes choses pouvant nuire aux autres utilisateurs.

19) Se comporter correctement avec les serveurs, laisser de la place aux autres

Que ce soit pour lire ou envoyer des articles, le logiciel NE DOIT PAS effectuer de demandes excessives aux serveurs de news sans nécessité. Le logiciel DOIT se limiter à 4 connexions simultanées à un serveur donné. Les connexions excédentaires et le trafic non nécessaire DOIVENT être évitées ; le logiciel DOIT utiliser aussi peu de connexions que possible, en réutilisant des connexions existantes à chaque fois qu'il le peut.

Raison : Les systèmes de news sont gros, les ressources sont limitées, et chaque ressource demandée est fournie au détriment des autres utilisateurs.

Je précise que l'ensemble de ces règles est un _minimum_ pour garantir qu'un logiciel donné communique correctement avec le reste de la communauté Usenet. Il ne s'agit pas d'une liste de souhaits d'une personne en particulier. J'ai délibérément évité de prendre position sur certains points controversés - par exemple, si l'utilisateur devrait pouvoir modifier le champ "Sender:", si les logiciels devraient empêcher de poster un article qui a plus de texte repris que de texte original, ou s'il devrait être interdit de poster avec certains sujets particuliers.

Mon souhait est qu'un comité de volontaires soit constitué, reconnu par la plupart des personnes utilisant Usenet, qu'il teste les logiciels de news existants et qu'il décide de l'attribution ou non du Brevet de Bon Citoyen d'Usenet (BBCU ou GNKSA en anglais). Les utilisateurs de logiciels qui n'ont pas obtenu le Brevet devraient alors être vivement encouragés à changer de logiciel.

Références et lectures supplémentaires

Le GNKSA actuel, un formulaire d'évaluation et une archive d'évaluations de logiciels [le tout en anglais - NdT] se trouvent aux adresses :

La page du GNKSA contient également un pointeur vers une bibliothèque que les développeurs de lecteurs de news peuvent utiliser librement, et qui fournissent des fonctions "sanitaires" de base.

En complément de ces règles, toute personne écrivant un logiciel de news devraait jeter un oeil attentif à ces deux documents :

D'excellentes collections de documents très intéressants dans ce contexte se trouvent aux adresses :

Un document très riche en informations au sujet de certaines formes d'abus du réseau, comment y réagir et comment ne pas y réagir, est :

[En français, on consultera sur les mêmes sujets les FAQs "Comment réagir aux messages abusifs" de Florent Faessel, et la FAQ "Les adresses invalides (antispam)" de Stéphane Marchau postées deux fois par mois sur fr.usenet.reponses et fr.usenet.abus.d.
http://www.usenet-fr.net/fur/usenet/abus/reagir-general.html
http://www.usenet-fr.net/fur/usenet/abus/reagir-conseils.html
http://www.usenet-fr.net/fur/minis-faqs/adresses-antispam.html
- NdT]

Si vous souhaitez contribuer, ou que vous êtes simplement intéressés par l'évolution des choses, vous pouvez aussi aller voir les travaux du NNTP Working Group de l'IETF "Projet de révision de NNTP pour le faire entrer dans les années 1990".
http://www.academ.com/academ/nntp/ietf.html

Remerciements

Simon Lyall c.s., pour l'initiative louable du Groupe de Travail UseFor (Usenet Format) et ses dérivées.

Ron Newman, évidemment, pour avoir écrit la première version du GNKSA, dont ce document descend, et pour des discussions fructueuses surant sa révision.

Sven Guckes, pour avoir fourni (entre autres choses) des ressources de listes de diffusion.

Tim Pierce, pour un examen attentif, des conseils utiles, et le soutien apporté au GNKSA précédent.

Larry Wall, Stefan Haller, John E. Davis, John Norstad, Karl-Johan Johnsson, Brian Clark, Simon Fraser pour avoir montré des exemples de l'esprit de bonne citoyenneté d'Usenet, sous la forme de logiciels de lecture de news d'une qualité de conception exceptionelle.

Les aimables lecteurs de news.software.readers (ils se reconnaîtront) qui ont aidé à discuter les points concernés par le principe du GNKSA.

[Le traducteur de la version 1.2 de ce document, dont le travail a servi de base au mien et que j'ai honteusement pillé. ;-) - NdT]

Valid XHTML 1.0! [Retour au Sommaire] Valid CSS!