Network Working Group S. Bradner
Request for Comments: 2119 Harvard University
BCP: 14 March 1997
Category: Best Current Practice
Palavras chave para usar em RFC indicando Níveis de Requisitos
Estatuto desde memorando
Este documento especifica as melhores práticas actuais na Internet para
a Comunidade da Internet e solicita discussão e sugestões para
melhorias. A distribuição deste memorando é ilimitada.
Sumário
Em vários documentos de acompanhamento de normas há várias palavras
que são usadas para identificar o grau de exigência na especificação.
Estas palavras são frequentemente escritas em letra maíscula. Este
documento define essas palavras tal como devem ser interpretadas nos
documento IETF. Os autores que seguem estas directrizes devem
incorporar esta frase perto do início dos seus documentos:
As palavras chave "É OBRIGATÓRIO (MUST)", "É PROIBIDO (MUST NOT)",
"EXIGIDO (REQUIRED)", "DEVE (SHALL)", "NÃO DEVE (SHALL NOT)",
"DEVERIA (SHOULD)", "NÃO DEVERIA (SHOULD NOT)", "RECOMENDADO
(RECOMMENDED)", "PODE (MAY)" e "OPCIONAL (OPTIONAL)" neste
documento são para serem interpretados como descrito no
RFC 2119.
Note que a força desta palavras se modifica pelo nível de requisito
do documento onde sejam usadas.
1. É OBRIGATÓRIO (MUST) Esta expressão ou as expressões
"EXIGIDO (REQUIRED)" ou "DEVE (SHALL)", significam que a
definição é um requisito absoluto da especificação.
2. É PROIBIDO (MUST NOT) Esta expressão ou a expressão "NÃO
DEVE (SHALL NOT)", significa que a definição é uma proibição
absoluta na especificação.
3. DEVERIA (SHOULD) Esta palavra, ou o adjectivo "RECOMENDADO
(RECOMMENDED)", significa que podem existir razões válidas em
circunstâncias determinadas para ignorar um item determinado mas
que as implicações todas devem ser compreendidas e cuidadosamente
pesadas antes de se escolher um curso diferente.
4. NÃO DEVERIA (SHOULD NOT) Esta expressão ou a expressão "NÃO
RECOMENDADO (NOT RECOMMENDED)" significam que podem existir
razões válidas em circunstâncias determinadas quando um
determinado comportamento é aceitável ou mesmo útil, mas que
é necessário compreender e o caso deve ser cuidadosamente
pesado antes de implementar qualquer comportamento descrito com
esta legenda.
5. PODE (MAY) Esta palavra ou o adjectivo "OPCIONAL (OPTIONAL)",
significa que um item é verdadeiramente opcional. Um fornecedor
poderá escolher incluir o item porque um determinado mercado o
exige ou porque o fornecedor sente que melhora o produto enquanto
outro fornecedor pode omitir o mesmo item. Uma implementação que
não inclua uma opção determinada É OBRIGADA a estar preparada para
inter-operar com outra implementação que inclua a opção, embora
talvez com funcionalidade reduzida. Na mesma onda uma
implementação que inclua uma opção determinada É OBRIGADA a estar
preparada para interagir com outra implementação que não inclua
a opção (excepto, claro, para a característica que a opção ofereça.)
6. Orientação no uso destes Imperativos
Os imperativos do tipo definido neste memorando têm que ser usados
com cuidado e parcimoniosamente. Em particular É OBRIGATÓRIO só os
usar onde sejam de facto necessários à inter-operação ou para
limitar comportamento que tenha potencial para causar dano
(por exemplo, limitar retransmissões). Por exemplo, não devem ser
usados para tentar impor um determinado método aos implementadores
quando o método não seja exigido para inter-operacionalidade.
7. Considerações de Segurança
Estes termos são frequentemente usados para especificar comportamento
com implicações de segurança. Os efeitos sobre a segurança de não
implementar um É OBRIGATÓRIO ou um DEVERIA, ou de efectuar algo que
a especificação diga É PROIBIDO ou NÃO DEVERIA ser feito pode ser
muito subtil. Os autores dos documentos devem levar tempo a pensar
sobre as implicações de segurança de não se seguir as recomendações
ou requisitos visto a maior parte dos implementadores não irão ter o
benefício da experiência e discussão que produzem a especificação.
8. Agradecimentos
As definições destes termos são uma amalgama de definições tomadas a
partir de um número de RFC. Além de terem sido feitas adições e
sugestões que foram incorporadas a partir de um número de pessoas
incluindo Robert Ullmann, Thomas Narten, Neal McBurnett e Robert Elz.
9. Endereço do Autor
Scott Bradner
Harvard University
1350 Mass. Ave.
Cambridge, MA 02138
phone - +1 617 495 3864
email - sob@harvard.edu
10. Tradução de Carlos Afonso
email - cafonso62@gmail.com
Nota: ver ISO/IEC Directives, Part 2: Rules for the structure and
drafting of International Standards [pdf].
