Aller au contenu principal

RFC 2119 - Mots-clés pour indiquer les niveaux d'exigence dans les RFC

  • Statut: Best Current Practice
  • Publication: March 1997
  • Stream: IETF
  • Errata: Aucune errata

État de ce mémo (Status of this Memo)​

Le présent document spécifie des meilleures pratiques actuelles pour la communauté Internet et invite à la discussion ainsi qu'à des suggestions d'amélioration. La distribution de ce mémo est illimitée.

Résumé (Abstract)​

Dans de nombreux documents de la série des standards, plusieurs mots sont utilisés pour indiquer les exigences de la spécification. Ces mots sont souvent en majuscules. Le présent document définit ces mots tels qu'ils doivent être interprétés dans les documents de l'IETF. Les auteurs qui suivent ces directives devraient inclure la phrase suivante près du début de leur document:

Les mots-clés "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" et "OPTIONAL" dans le présent document doivent être interprétés comme décrit dans le RFC 2119.

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

1. MUST (doit)​

Ce mot, ou les termes "REQUIRED" ou "SHALL", signifie que la définition constitue une exigence absolue de la spécification.

2. MUST NOT (ne doit pas)​

Cette expression, ou l'expression "SHALL NOT", signifie que la définition constitue une interdiction absolue de la spécification.

3. SHOULD (devrait)​

Ce mot, ou l'adjectif "RECOMMENDED", signifie qu'il peut exister des raisons valables, dans des circonstances particulières, d'ignorer un élément donné, mais que les implications complètes doivent être comprises et soigneusement pesées avant de choisir une autre voie.

4. SHOULD NOT (ne devrait pas)​

Cette expression, ou l'expression "NOT RECOMMENDED", signifie qu'il peut exister des raisons valables, dans des circonstances particulières, pour lesquelles le comportement décrit est acceptable voire utile, mais que les implications complètes doivent être comprises et le cas soigneusement pesé avant de mettre en œuvre tout comportement décrit par cette étiquette.

5. MAY (peut)​

Ce mot, ou l'adjectif "OPTIONAL", signifie qu'un élément est véritablement facultatif. Un fournisseur peut choisir d'inclure l'élément parce qu'un marché particulier l'exige ou parce qu'il estime que cela améliore le produit, tandis qu'un autre fournisseur peut omettre le même élément. Une mise en œuvre qui n'inclut pas une option particulière MUST être prête à interopérer avec une autre mise en œuvre qui inclut l'option, éventuellement avec une fonctionnalité réduite. De même, une mise en œuvre qui inclut une option particulière MUST être prête à interopérer avec une autre mise en œuvre qui n'inclut pas l'option (sauf, bien entendu, pour la fonctionnalité que l'option fournit).

6. Conseils sur l'utilisation de ces impératifs (Guidance in the use of these Imperatives)​

Les impératifs du type défini dans ce mémo doivent être utilisés avec prudence et avec parcimonie. En particulier, ils MUST n'être utilisés que lorsqu'ils sont réellement nécessaires à 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 imposer une méthode particulière aux implémenteurs lorsque cette méthode n'est pas requise pour l'interopérabilité.

7. Considérations de sécurité (Security Considerations)​

Ces termes sont fréquemment utilisés pour spécifier un comportement ayant des implications de sécurité. Les effets sur la sécurité de ne pas mettre en œuvre un MUST ou un SHOULD, ou de faire quelque chose que la spécification indique comme MUST NOT ou SHOULD NOT, peuvent être très subtils. Les auteurs de documents devraient prendre le temps d'expliciter les implications de sécurité liées au non-respect des recommandations ou exigences, car la plupart des implémenteurs n'auront pas bénéficié de l'expérience et des discussions ayant produit la spécification.

8. Remerciements (Acknowledgments)​

Les définitions de ces termes sont un amalgame de définitions tirées de plusieurs RFC. Des suggestions ont en outre été incorporées de la part de plusieurs personnes, notamment Robert Ullmann, Thomas Narten, Neal McBurnett et Robert Elz.

9. Adresse de l'auteur (Author's Address)​

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

phone - +1 617 495 3864
email - [email protected]

Références (References)​