Le RFC 2119 de l’auteur Scott Bradner de l’Université Harvard de Cambridge, a été interprété en allemand par Jean-Louis Fuchs d’Adfinis SyGroup. Il ne s’agit pas d’une traduction littérale, mais d’une interprétation en allemand. Le but de cette interprétation est de rendre la RFC 2119 disponible et de la diffuser dans les pays germanophones.
La RFC 2119 traite des mots-clés dans les documents pour indiquer l’exigence de la spécification.
La version originale peut être trouvé sur GitHub.

Mots-clés pour identifier les besoins

Statut de ce mémorandum

Basé sur la RFC 2119, ce document définit des mots-clés pour identifier les demandes. Il ne s’agit pas d’une traduction, mais d’une interprétation pour les germanophones, de sorte que cet excellent outil peut également être utilisé pour la documentation allemande.

Résumé

Dans le processus de normalisation, des mots-clés sont utilisés dans de nombreux documents pour indiquer les exigences de la spécification. Ces mots sont souvent en majuscules. Les auteurs qui suivent ces lignes directrices devraient inclure la phrase suivante au début de leur document :
Les mots-clés "MUST", "SHALL NOT", "REQUIRED", "SHALL", "PROHIBITED", "NECESSARED", "NOT NECESSARED", "SHALL NOT", "RECOMMENDED", "SHALL", "CAN" et "OPTIONAL" sont interprétés après 2119de. https://goo.gl/6QZH4J
Notez que l’expressivité de ces mots peut être relativisée par les exigences du document dans lequel ils sont utilisés.

Définition

1. MUST
ou les mots-clés “REQUIS” ou “NECESSAIRE” signifient que la définition est une exigence absolue de la spécification.

2. MUST NOT
ou le mot “INTERDIT” signifie que la définition est une interdiction absolue de la spécification.

3. SHOULD
ou l’adjectif “RECOMMANDÉ” signifie que dans des situations particulières, il peut y avoir des raisons d’ignorer cette spécification. Bien entendu, les effets doivent être bien compris et soigneusement pesés avant de s’écarter des spécifications.

4. SHOULD NOT
ou “NON RECOMMANDÉ” signifie qu’il peut y avoir de bonnes raisons, dans des situations spécifiques, pour que ce comportement soit acceptable, voire utile. Bien entendu, les effets doivent être bien compris et soigneusement pesés avant de s’écarter des spécifications.

5. MAY
ou “CAN”, “CAN’T”, “CAN’T”, “CAN’T” ou l’adjectif “OPTIONNEL” signifient que ce comportement est vraiment facultatif.
Important lors de la définition d’une interaction ou d’un protocole : Un fournisseur peut décider d’inclure ce comportement car il améliore le produit ou est nécessaire pour un marché spécifique. Un autre fournisseur peut omettre ce comportement. Une implémentation qui omet ce comportement DOIT être prête à interagir avec une autre implémentation qui inclut ce comportement. De la même manière, une implémentation qui inclut ce comportement DOIT être capable d’interagir avec une implémentation qui omet ce comportement.
Note en allemand : Tous les mots-clés PEUVENT être déclinés et conjugués. La majuscule est suffisante pour reconnaître les mots-clés. “NOT” peut être remplacé par “NO”, comme d’habitude en allemand.

6. Conseils sur l’utilisation de ces impératifs

Les impératifs du type défini dans la présente note doivent être utilisés avec prudence et parcimonie. En particulier, ils NE DOIVENT être utilisés que lorsqu’ils sont réellement nécessaires pour l’interopérabilité ou pour limiter un comportement susceptible de causer un préjudice (par exemple, limiter les retransmissions). Par exemple, ils ne doivent pas être utilisés pour essayer d’imposer une méthode particulière aux implémenteurs lorsque la méthode n’est pas nécessaire pour l’interopérabilité.

7. Considérations de sécurité
Ces termes sont fréquemment utilisés pour préciser les comportements ayant des implications en matière de sécurité. Les effets sur la sécurité du fait de ne pas mettre en œuvre un MUST ou un SHOULD, ou de faire quelque chose que la spécification dit MUST NOT ou SHOULD NOT faire, peuvent être très subtils. Les auteurs des documents devraient prendre le temps d’expliquer les conséquences sur la sécurité du non-respect des recommandations ou des exigences, car la plupart des responsables de la mise en œuvre n’auront pas bénéficié de l’expérience et de la discussion qui ont produit les spécifications.

8. Remerciements
Les définitions de ces termes sont un amalgame de définitions tirées d’un certain nombre de RFC. De plus, un certain nombre de personnes, dont Robert Ullmann, Thomas Narten, Neal McBurnett et Robert Elz, ont fait des suggestions.

9. Author’s Address

Scott Bradner
Harvard University
1350 Mass. Ave.
Cambridge, MA 02138

phone – +1 617 495 3864

email – sob@harvard.edu