Passa al contenuto principale

RFC 2119 - Parole chiave per indicare i livelli di requisito negli RFC

  • Stato: Best Current Practice
  • Pubblicato: March 1997
  • Stream: IETF
  • Errata: Nessun errata

Stato di questo memo (Status of this Memo)​

Il presente documento specifica le Best Current Practices Internet per la comunità Internet e richiede discussione e suggerimenti per miglioramenti. La distribuzione di questo memo è illimitata.

Sommario (Abstract)​

In molti documenti della serie standards track vengono usate diverse parole per indicare i requisiti della specifica. Queste parole sono spesso scritte in maiuscolo. Il presente documento definisce tali parole come devono essere interpretate nei documenti IETF. Gli autori che seguono queste linee guida dovrebbero includere la seguente frase vicino all'inizio del proprio documento:

Le parole chiave "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" e "OPTIONAL" nel presente documento devono essere interpretate come descritto in RFC 2119.

Si noti che la forza di queste parole è modificata dal livello di requisito del documento in cui sono usate.

1. MUST (deve)​

Questa parola, o i termini "REQUIRED" o "SHALL", significa che la definizione è un requisito assoluto della specifica.

2. MUST NOT (non deve)​

Questa frase, o la frase "SHALL NOT", significa che la definizione è un divieto assoluto della specifica.

3. SHOULD (dovrebbe)​

Questa parola, o l'aggettivo "RECOMMENDED", significa che possono esistere ragioni valide in circostanze particolari per ignorare un particolare elemento, ma le implicazioni complete devono essere comprese e attentamente valutate prima di scegliere un corso diverso.

4. SHOULD NOT (non dovrebbe)​

Questa frase, o la frase "NOT RECOMMENDED", significa che possono esistere ragioni valide in circostanze particolari in cui il comportamento descritto è accettabile o addirittura utile, ma le implicazioni complete dovrebbero essere comprese e il caso attentamente valutato prima di implementare qualsiasi comportamento descritto con questa etichetta.

5. MAY (può)​

Questa parola, o l'aggettivo "OPTIONAL", significa che un elemento è davvero opzionale. Un fornitore può scegliere di includere l'elemento perché un particolare mercato lo richiede o perché ritiene che migliori il prodotto, mentre un altro fornitore può omettere lo stesso elemento. Un'implementazione che non include una particolare opzione MUST essere preparata a interoperare con un'altra implementazione che include l'opzione, magari con funzionalità ridotta. Allo stesso modo, un'implementazione che include una particolare opzione MUST essere preparata a interoperare con un'altra implementazione che non include l'opzione (tranne, ovviamente, per la funzionalità che l'opzione fornisce).

6. Guida sull'uso di questi imperativi (Guidance in the use of these Imperatives)​

Gli imperativi del tipo definito in questo memo devono essere usati con cura e parsimonia. In particolare, MUST essere usati solo dove è effettivamente richiesto per l'interoperazione o per limitare un comportamento che ha il potenziale di causare danni (ad esempio, limitare le ritrasmissioni). Ad esempio, non devono essere usati per imporre un particolare metodo agli implementatori dove il metodo non è richiesto per l'interoperabilità.

7. Considerazioni sulla sicurezza (Security Considerations)​

Questi termini sono frequentemente usati per specificare comportamenti con implicazioni di sicurezza. Gli effetti sulla sicurezza di non implementare un MUST o un SHOULD, o di fare qualcosa che la specifica indica come MUST NOT o SHOULD NOT, possono essere molto sottili. Gli autori dei documenti dovrebbero prendersi il tempo di elaborare le implicazioni di sicurezza del non seguire raccomandazioni o requisiti, poiché la maggior parte degli implementatori non avrà avuto il beneficio dell'esperienza e della discussione che hanno prodotto la specifica.

8. Ringraziamenti (Acknowledgments)​

Le definizioni di questi termini sono un amalgama di definizioni prese da un certo numero di RFC. Inoltre, sono stati incorporati suggerimenti di diverse persone tra cui Robert Ullmann, Thomas Narten, Neal McBurnett e Robert Elz.

9. Indirizzo dell'autore (Author's Address)​

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

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

Riferimenti (References)​