Groupe de travail Réseau	S. Bradner
Request for Comments : 2119	Harvard University
BCP : 14		mars 1997
Catégorie : Guide de bonne conduite

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) : 
Ce mot, ou les termes "EXIGE" (REQUIRED ou SHALL), signifie que la définition est une exigence absolue de la spécification.

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