Versão rascunho de trabalho de tradução

Documento em processo de tradução. Não é seguro usar como referência! Aguarde lançamento da versão candidata a lançamento ou a versão estável.

Citação desta tradução em documentos

É RECOMENDÁVEL que autores de documentação, ao seguir estas diretrizes com termos traduzidos para português aqui incorporem a seguinte frase próximo ao início do seu documento:

É RECOMENDÁVEL remover palavras-chave não usadas no documento. É OPCIONAL omitir endereço eletrônico que disponibiliza a tradução.

Tradução

Network Working Group                                         S. Bradner
Pedido de Comentários: 2119                      Universidade de Harvard
BCP: 14                                                       Março 1997
Categoria: Melhores Práticas Atuais


  Palavras-chave para o uso nas RFCs para Indicar Níveis de Exigência

Situação deste Memorando

   Este documento especifica uma das Melhores Práticas Atuais da
   Internet para a Comunidade da Internet, e pede discussão e sugestões
   para melhorias. A distribuição deste memorando é ilimitada.

Resumo

   Em muitos documentos tramitando para se tornar padrões diversas
   paravras são usadas para indicar requisidos na especificação. Essas
   palavras estão frequentemente em maiúsculo. Este documento define o
   modo como estas palavras devem ser interpretadas em documentos da
   IETF. Autores que sigam estas diretrizes devem incorporar esta frase
   próximo do início do seu documento:

      As palavras-chave "DEVE", "NÃO DEVE", "REQUER", "DEVERIA", "NÃO
      DEVERIA", "PODERIA", "NÃO PODERIA", "RECOMENDÁVEL", "PODE", e
      "OPCIONAL" neste documento devem ser interpretadas como descritas
      no RFC 2119.

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

1. DEVE   Esta palavra, ou os termos "REQUER" ou "DEVERIA", significa
   que a definição é uma exigência absoluta da especificação.

2. NÃO DEVE   Esta frase, ou a frase "NÃO DEVERIA", significa que a
   definição é uma proibição absoluta da especificação.

3. PODERIA   Esta palavra, ou o adjetivo "RECOMENDÁVEL" significa que
   podem existir razões válidas em circunstâncias particulares para
   ignorar um item específico, mas todas as implicações devem ser
   compreendidas e cuidadosamente ponderadas antes de escolher um
   curso diferente.

4. NÃO PODERIA   Esta frase, ou a frase "NÃO RECOMENDÁVEL", significa
   que podem existir razões validas em circunstâncias particulares
   em que um comportamento é aceitável ou mesmo útil, mas todas as
   implicações devem ser compreendidas e cuidadosamente poderadas
   antes de implementar qualquer comportamento descrito com essa
   rotulagem.


Bradner               Melhores Práticas Atuais                [Página 1]

RFC 2119               Palavras-chave em RFC                  Março 1997


5. PODE   Esta palavra, ou o adjetivo "OPCIONAL", significa que um item
   é realmente opcional. Um fornecedor pode optar por incluir o item
   porque um mercado em particular o requer ou porque o fornecedor sente
   que isso melhora o produto enquanto outro fornecedor pode omitir o
   mesmo item. Uma implementação que não incluir esta opção em particular
   DEVE estar preparada para interoperar com outra aplicação que incluir
   a opção, embora possivelmente com funcionalidade reduzida. No mesmo
   sentido, uma implementação que inclui a opção em particular DEVE
   estar preparada para interoperar com outra implementação que que
   não inclui a opção (exceto, é claro, para funcionalidade que a opção)
   fornece.)

6. Orientação no uso desses Imperativos

   Imperativos do tipo definido no presente memorando devem ser
   utilizado com cuidado e moderação. Em particular, eles DEVEM ser
   usados somente onde são realmente exigidos para interoper ou para
   limitar um comportamento potencialmente danoso (i.e. limitar
   retransmissões). Por exemplo, eles não devem ser usados para tentar
   impor um método em particular quando o método não é requerido para
   interoperabilidade.

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 DEVE ou PODERIA, ou fazer algo que a especificação diz
   NÃO DEVERIA ou NÃO PODERIA ser feito pode ser muito sutil. Autores de
   documentação devem dedicar tempo para elaborar as implicações de
   segurança de não seguir recomendações ou requisitos visto que a
   maioria dos implementadores não tiveram o benefício da experiêcia
   e da discussão que produziu a especificação.

8. Agradecimentos

   As definições destes termos são uma amálgama de definições tomadas de
   vários RFCs. Além disso, foram incorporadas sugestões de várias
   pessoas incluindo Robert Ullmann, Thomas Narten, Neal McBurnett, e
   Robert Elz.












Bradner               Melhores Práticas Atuais                [Página 2]

RFC 2119               Palavras-chave em RFC                  Março 1997


9. Endereço do Autor

      Scott Bradner
      Universidade de Harvard
      1350 Mass. Ave.
      Cambridge, MA 02138

      telefone - +1 617 495 3864

      email - sob@harvard.edu









































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

Tabela de equivalência

A tabela a seguir exibe as palavras-chave em inglês e a tradução para português.

  • MUST e sinônimos
    • MUST: DEVE, DEVEM
    • REQUIRED: REQUER
    • SHALL: DEVERIA, DEVERIAM
  • MUST NOT e sinônimos
    • MUST NOT: NÃO DEVE, NÃO DEVEM
    • SHALL NOT: NÃO DEVERIA
  • SHOULD e sinônimos
    • SHOULD: PODERIA, PODERIAM
    • RECOMMENDED: RECOMENDÁVEL
  • SHOULD NOT
    • SHOULD NOT: NÃO PODERIA
    • NOT RECOMMENDED: NÃO RECOMENDÁVEL
  • MAY e sinônimos
    • MAY: PODE, PODEM
    • OPTIONAL: OPCIONAL