Groupe de travail Réseau   S. Bradner

Request for Comments : 2119   Harvard University

BCP : 14      mars 1997

Catégorie : Guide de bonne conduite

Traduction : Claude Brière de L'Isle

Mots clé à utiliser dans les RFC pour indiquer les niveaux d’exigence

Statut du présent mémo

Le présent document spécifie un guide de bonne conduite pour la communauté de l’Internet, et appelle à discussion et suggestions d’améliorations. La distribution du présent mémo n’est pas soumise à restrictions.

Résumé

Dans de nombreux document de normalisation, plusieurs mots sont utilisés pour signifier les exigences de la spécification. Ces mots sont souvent en majuscules. Le présent document définit ces mots et leur interprétation dans les documents de l’IETF. Les auteurs qui suivent ces lignes directrices devraient incorporer la phrase suivante près du début de leur document :

Les mots clé "DOIT", "NE DOIT PAS", "EXIGE", "DEVRAIT", "NE DEVRAIT PAS", "DEVRA", "NE DEVRA PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" dans le présent document sont à interpréter comme décrit dans la RFC 2119 .

Noter que la force de ces mots est modifiée par le niveau d’exigence du document dans lequel ils sont utilisés.

1. DOIT ou DEVRA (MUST ou SHALL) :

2.   NE DOIT PAS ou NE DEVRA PAS (MUST NOT ou SHALL NOT) :

Cette phrase signifie que la définition est une interdiction absolue de la spécification.

3.   DEVRAIT (SHOULD) :

Ce mot, ou l’adjectif "RECOMMANDÉ", signifie qu’il peut exister des raisons valables dans des circonstances particulières pour ignorer un élément précis, mais toutes les implications doivent être comprises et soigneusement pesées avant de choisir une voie différente.

4.   NE DEVRAIT PAS (SHOULD NOT) :

Cette phrase, ou la phrase "NON RECOMMANDÉ" signifie qu’il peut exister des raisons valables dans des circonstances particulières où un comportement particulier est acceptable ou même utile, mais toutes ses implications devraient être comprises et le cas soigneusement pesé avant de mettre en œuvre un comportement décrit avec cette notation.

5.   PEUT (MAY) :

Ce mot, ou l’adjectif "FACULTATIF" (OPTIONAL), signifie qu’un élément est vraiment facultatif. Un fabricant peut choisir d’inclure l’élément parce que un secteur particulier du marché le réclame ou parce que le fabricant pense que cela améliore le produit tandis qu’un autre fabricant peut omettre le même élément. Une mise en œuvre qui n’inclut pas une option particulière DOIT pouvoir interopérer avec une autre mise en œuvre qui n’inclut pas l’option, peut-être au prix de fonctionnalités réduites. Dans la même veine, une mise en œuvre qui n’inclut pas une option particulière DOIT être préparée à interopérer avec une autre mise en œuvre qui n’inclut pas l’option (excepté, bien sûr, pour la caractéristique fournie par l’option).

6.   Lignes directrices pour l’utilisation de ces exigences

Les exigences du type défini dans le présent mémo doivent être utilisées avec soin et discernement. En particulier, elles ne DOIVENT être utilisées que lorsque c’est réellement nécessaire pour l’interopérabilité ou pour limiter des comportements potentiellement dommageables (par exemple, en limitant les retransmissions). Par exemple, elles ne doivent pas être utilisées pour essayer d’imposer une méthode particulière aux développeurs lorsque la méthode n’est pas exigée pour l’interopérabilité.

7.   Considérations sur la sécurité

Les présents termes sont fréquemment utilisés pour spécifier des comportements ayant des implications de sécurité. Les effets sur la sécurité de la mise en œuvre ou non mise en œuvre d’un DOIT ou d’un DEVRAIT, ou de faire quelque chose que la spécification dit NE DOIT PAS ou NE DEVRAIT PAS être fait peut être très subtile. Les utilisateurs des documents devraient prendre le temps d’élaborer les implications sur la sécurité de ne pas suivre les recommandations ou exigences car la plupart des mises en œuvre ne bénéficieront pas de l’expérience et des discussions produites par la spécification.

8.   Remerciements

Les définitions de ces termes sont un amalgame des définitions tirées d’un certain nombre de RFC. De plus, des suggestions supplémentaires ont été incorporées provenant de plusieurs personnes parmi lesquelles Robert Ullmann, Thomas Narten, Neal McBurnett, et Robert Elz.

9.   Adresse de l’auteur

Scott Bradner

Harvard University

1350 Mass. Ave.

Cambridge, MA 02138

téléphone - +1 617 495 3864

mél - sob@harvard.edu