Admirável Mundo Novo: Tudo Sobre Asterisk, OpenSER, Linux e Tecnologias de Voz sobre IP

Grupo de Trabalho em Rede                                     S. Bradner
Request for Comments: 2119                            Harvard University
BCP: 14                                                       Março 1997
Categoria: Best Current Practice





Palavras-Chaves para uso em RFC's para Indicar Níveis de Exigências


Status desse Memorando

Esse documento especifica um Internet Best Current Practices (Melhores Práticas Atuais na Internet) na Comunidade Internet e requisita discussões e sugestões para melhoramentos. A distribuição desse memorando é ilimitada.


Resumo

Em muitos documentos tramitando para se tornar padrões várias palavras são usadas para indicar os requisitos na especificação. Essas palavras são freqüentemente em maiúsculo. Esse documento define essas palavras do modo como elas devem ser interpretadas em documentos do IETF. Autores que seguem essas orientações devem acrescentar essa frase ao seu documento próximo ao início:

As palavras chaves "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", e "OPTIONAL" nesse documento devem ser interpretadas como descrita na RFC 2119.

Note que a força dessas palavras-verbos é modificada pelo nível de exigência do documento no qual elas são usadas.


1. MUST
Essa palavra, ou os termos "REQUIRED" ou "SHALL", significam que a definição é uma exigência absoluta da especificação.

O verbo MUST exprime obrigatoriedade, algo mandatório, exigido, forçoso, requerido, necessário e preciso. Na tradução das RFC's do SIP para o português, aqui no blog, será traduzido como sinônimo de: PRECISAR, REQUERER, OBRIGAR, EXIGIR, FORÇAR, SER OBRIGATÓRIO, SER FORÇOSO, NECESSITAR, SER MANDATORIO.


2. MUST NOT
Essa frase, ou a frase "SHALL NOT", significam que a definição é uma proibição absoluta da especificação.
Em português equivale a: NÃO PODE, É PROIBIDO, É VEDADO.


3. SHOULD
Essa palavra, ou o adjetivo "RECOMMENDED", significam que pode haver razões válidas em circunstâncias particulares para se ignorar um item particular, mas as implicações completas precisam ser compreendidas e cuidadosamente ponderadas antes de se escolher um curso diferente.
Em português equivale a: DEVE, É RECOMENDADO.


4. SHOULD NOT
Essa frase, ou a frase "NOT RECOMMENDED" significam que pode haver razões válidas em circunstâncias particulares quando o comportamento particular é aceitável ou mesmo útil, mas as implicações completas devem ser compreendidas e o caso cuidadosamente ponderado antes de implementar qualquer comportamento descrito com esse rótulo.
Em português equivale a: NÃO DEVE, NÃO É RECOMENDADO.




Bradner                  Melhores Práticas Atuais                  [Página 1]



RFC 2119                     RFC Palavras-Chaves                    Março 1997


5. MAY
Essa palavra, ou o adjetivo "OPTIONAL", significa que um item é opcional verdadeiramente. Um fabricante pode escolher incluir o item como um mercado particular o exige ou porque o fabricante percebe que isso melhora o produto ao passo que outro fabricante pode omitir o mesmo item. Uma implementação que não inclui uma opção particular PRECISA estar preparada para interoperar com outra implementação que inclui a opção, embora, possivelmente com funcionalidades reduzidas. Nessa mesma disposição, uma implementação que inclui uma opção particular PRECISA estar preparada para interoperar com outra implementação que não inclui a opção (exceto claro, para o recurso que a opção fornece). Em português equivale a: PODE, É OPCIONAL.


6. Orientação no uso desses Imperativos

Imperativos do tipo definidos nesse memorando precisam ser usados com cuidado e parcimônia. Em particular, eles PRECISAM ser usados somente onde é realmente exigido para interoperar ou para limitar comportamento que possui potencial para causar prejuízo (por exemplo, limitar re-transmissões). Por exemplo, eles não precisam ser usados para tentar impor um método particular aos implementadores no lugar onde o método não for obrigatório para a finalidade interoperabilidade.


7. Considerações de Segurança

Esses termos são freqüentemente usados para especificar comportamento com implicações de segurança. Os efeitos sobre a segurança de não implementar um PRECISA ou um DEVE, ou fazer algo que a especificação diz NÃO PRECISA ou NÂO DEVE ser feito pode ser muito sútil. Autores de documento devem despender algum tempo para elaborar as implicações de segurança para o não seguir recomendações ou exigências porque a maioria dos implementadores não tiveram o benefício da experiência e da discussão que produziu a especificação.


8. Reconhecimentos

As definições desses termos são o amálgama de definições tomadas de inúmeras RFC's. Em adição, sugestões têm sido incorporadas a partir de inúmeras pessoas incluindo Robert Ullmann, Thomas Narten, Neal McBurnett e Robert Elz.












Bradner                  Melhores Práticas Atuais                  [Página 2]



RFC 2119                     RFC Palavras-Chaves                    Março 1997


9. Endereço do Autor

Scott Bradner
Harvard University
1350 Mass. Ave.
Cambridge, MA 02138
phone - +1 617 495 3864
email - sob@harvard.edu






































Bradner                  Melhores Práticas Atuais                  [Página 3]