-
Notifications
You must be signed in to change notification settings - Fork 1
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
#4 RCF 2119, BCP 14: tradução, traduzido SHOULD NOT, MAY, 6. Guidance…
…~, 7. Security~, 8. Agradecimentos e 9. Author's Address; Alterado RECOMENDADO para RECOMENDÁVEL
- Loading branch information
Showing
1 changed file
with
45 additions
and
47 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -82,65 +82,63 @@ Resumo | |
definição é uma proibição absoluta da especificação. | ||
|
||
3. PODERIA Esta palavra, ou o adjetivo "RECOMENDADO" significa que | ||
podem existir razões válidas em circustâncias particulares para | ||
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. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that | ||
there may exist valid reasons in particular circumstances when the | ||
particular behavior is acceptable or even useful, but the full | ||
implications should be understood and the case carefully weighed | ||
before implementing any behavior described with this label. | ||
|
||
|
||
|
||
4. NÃO PODERIA Esta frase, ou a frase "NÃO RECOMENDAVEL", 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. MAY This word, or the adjective "OPTIONAL", mean that an item is | ||
truly optional. One vendor may choose to include the item because a | ||
particular marketplace requires it or because the vendor feels that | ||
it enhances the product while another vendor may omit the same item. | ||
An implementation which does not include a particular option MUST be | ||
prepared to interoperate with another implementation which does | ||
include the option, though perhaps with reduced functionality. In the | ||
same vein an implementation which does include a particular option | ||
MUST be prepared to interoperate with another implementation which | ||
does not include the option (except, of course, for the feature the | ||
option provides.) | ||
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. Guidance in the use of these Imperatives | ||
6. Orientação no uso desses Imperativos | ||
|
||
Imperatives of the type defined in this memo must be used with care | ||
and sparingly. In particular, they MUST only be used where it is | ||
actually required for interoperation or to limit behavior which has | ||
potential for causing harm (e.g., limiting retransmisssions) For | ||
example, they must not be used to try to impose a particular method | ||
on implementors where the method is not required for | ||
interoperability. | ||
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. Security Considerations | ||
7. Considerações de Segurança | ||
|
||
These terms are frequently used to specify behavior with security | ||
implications. The effects on security of not implementing a MUST or | ||
SHOULD, or doing something the specification says MUST NOT or SHOULD | ||
NOT be done may be very subtle. Document authors should take the time | ||
to elaborate the security implications of not following | ||
recommendations or requirements as most implementors will not have | ||
had the benefit of the experience and discussion that produced the | ||
specification. | ||
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. Acknowledgments | ||
8. Agradecimentos | ||
|
||
The definitions of these terms are an amalgam of definitions taken | ||
from a number of RFCs. In addition, suggestions have been | ||
incorporated from a number of people including Robert Ullmann, Thomas | ||
Narten, Neal McBurnett, and Robert Elz. | ||
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. | ||
|
||
|
||
|
||
|
@@ -158,14 +156,14 @@ Bradner Melhores Práticas Atuais [Página 2] | |
RFC 2119 Palavras-chave em RFC Março 1997 | ||
|
||
|
||
9. Author's Address | ||
9. Endereço do Autor | ||
|
||
Scott Bradner | ||
Harvard University | ||
Universidade de Harvard | ||
1350 Mass. Ave. | ||
Cambridge, MA 02138 | ||
|
||
phone - +1 617 495 3864 | ||
telefone - +1 617 495 3864 | ||
|
||
email - [email protected] | ||
|
||
|
@@ -224,10 +222,10 @@ Bradner Melhores Práticas Atuais [Página 3] | |
- <em lang="en">SHALL NOT</em>: NÃO DEVERIA | ||
- <em lang="en">SHOULD</em> e sinônimos | ||
- <em lang="en">SHOULD</em>: PODERIA, PODERIAM | ||
- <em lang="en">RECOMMENDED</em>: RECOMENDADO, RECOMENDÁVEL | ||
- <em lang="en">RECOMMENDED</em>: RECOMENDÁVEL | ||
- <em lang="en">SHOULD NOT</em> | ||
- <em lang="en">SHOULD NOT</em>: NÃO PODERIA | ||
- <em lang="en">NOT RECOMMENDED</em>: NÃO RECOMENDADO, NÃO RECOMENDÁVEL | ||
- <em lang="en">NOT RECOMMENDED</em>: NÃO RECOMENDÁVEL | ||
- <em lang="en">MAY</em> e sinônimos | ||
- <em lang="en">MAY</em>: PODE, PODEM | ||
- <em lang="en">OPTIONAL</em>: OPCIONAL |