Network Working Group S.Bradner Request for Comments: 2119 Harvard University BCP: 14 Marzo 1997 Categoría: Mejor Práctica Actual Palabras clave a utilizar en RFC para Indicar Niveles de Requerimiento Estatus de este memorándum Este documento especifica una Mejor Práctica Actual de Internet para la comunidad Internet, y solicita su discusión y sugerencias para posibles mejoras. La distribución de este memorándum es ilimitada. Resúmen En muchos documentos de seguimiento de estándar se usan varias palabras para indicar los requerimientos de la especificación. Estas palabras a menudo están en mayúsculas. Este documento define cómo deberían ser interpretadas estas palabras en documentos IETF. Los autores que sigan estas instrucciones deberían incorporar esta frase cerca del principio de sus documentos: Las palabras clave "DEBE", "NO DEBE", "OBLIGATORIO", "DEBERÁ", "NO DEBERÁ", "DEBERÍA", "NO DEBERÍA", "RECOMENDADO", "PUEDE" y "OPCIONAL" en este documento serán interpretadas como se describe en RFC 2119. Nótese que la contundencia de estas palabras está modificada por el nivel de requerimiento del documento en el que son usadas. 1. DEBE Esta palabra, o los términos "OBLIGATORIO" o "DEBERÁ", significa que la definición es un requerimiento insoslayable de la especificación. 2. NO DEBE Esta frase, o la frase "NO DEBERÁ", significa que la definición es una prohibición insoslayable de la especificación. 3. DEBERÍA Esta palabra, o el adjetivo "RECOMENDADO", significa que pueden existir razones válidas en determinadas circunstancias para ignorar un elemento determinado, pero se deben comprender y sopesar detenidamente todas las implicaciones antes de tomar una decisión diferente. 4. NO DEBERÍA Esta frase, o la frase "NO RECOMENDADO", significa que pueden existir razones válidas en determinadas circunstancias en las que el comportamiento en particular sea útil o incluso aconsejable, pero se deben comprender y sopesar detenidamente todas las implicaciones antes de tomar una decisión diferente. Bradner Mejor Práctica Actual [Pág. 1] RFC 2119 Palabras Clave RFC Marzo 1997 5. PUEDE Esta palabra, o el adjetivo "OPCIONAL", significa que un elemento es realmente opcional. Un proveedor puede elegir incluir el elemento porque un mercado en particular lo necesite o porque el proveedor sienta que realza el producto aunque otro proveedor pueda omitir el mismo elemento. Una implementación que no incluya una opción determinada DEBE estar preparada para interoperar con otra implementación que incluya la opción, aunque quizá con reducida funcionalidad. En el mismo orden de cosas, una implementación que incluya una opción en particular DEBE estar preparada para interoperar con otra implementación que no incluya la opción (excepto, por supuesto, para la característica que aporte la opción). 6. Guia de uso de estos Imperativos Los imperativos del tipo definido en este memorándum deben ser usados con cuidado y con mesura. En particular, sólo DEBEN ser utilizados donde sea realmente necesario para la interoperación o para limitar un comportamiento potencialmente dañino (p.ej., limitando retransmisiones). Por ejemplo, no deben ser usados para intentar imponer un método concreto a los implementadores cuando el método no sea necesario para la interoperabilidad. 7. Consideraciones de seguridad Estos términos se utilizan normalmente para especificar comportamientos con implicaciones de seguridad. Los efectos sobre la seguridad de no implementar un DEBE o DEBERÍA, o hacer algo que la especificación dice NO DEBE o NO DEBERÍA ser hecho, pueden ser muy sutiles. Los autores de documentos deberían tomarse su tiempo para eleborar las implicaciones de seguridad respecto a no seguir recomendaciones o requerimientos, ya que la mayoría de los implementadores no tienen el beneficio de la experiencia y de la discusión que produjo la especificación. 8. Agradecimientos Las definiciones de estos términos son una amalgama de las definiciones tomadas de numerosos documentos RFC. Además, se han incorporado sugerencias de numerosas personas incluyendo a obert Ullmann, Thomas Nartenm Neal McBurnett, y Robert Elz. 9. Dirección del autor Scott Bradner Harvard University 1350 Mass. Ave. Cambridge, MA 02138 phone - +1 617 495 3864 Bradner Mejor Práctica Actual [Pág. 2] RFC 2119 Palabras Clave RFC Marzo 1997 email - sob@harvard.edu Traducción al castellano: José M. Caínzos jmcainzos@vodafone.es SEVILLA -SPAIN Bradner Mejor Práctica Actual [Pág. 3]