RFC 2119, titulado "Key words for use in RFCs to Indicate Requirement Levels", es un documento técnico publicado por el Internet Engineering Task Force (IETF) que establece un conjunto de palabras clave estandarizadas para indicar los niveles de requisito en las especificaciones técnicas. Estas palabras clave son: 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', y 'OPTIONAL'. Su propósito es eliminar ambigüedades y asegurar que los implementadores y desarrolladores comprendan claramente qué partes de una especificación son obligatorias, recomendadas o discrecionales.
La implementación de RFC 2119 es ubicua en el mundo de la estandarización técnica, especialmente en documentos del IETF y otras organizaciones de estándares. Por ejemplo, todos los Request for Comments (RFCs) subsiguientes que definen protocolos de Internet (como HTTP/1.1 en RFC 2616, o TLS en RFC 5246) utilizan estas palabras clave para especificar el comportamiento de clientes y servidores. Otros estándares de la industria, aunque no directamente RFCs, a menudo adoptan esta convención para la claridad en sus propias especificaciones, como algunos documentos de la World Wide Web Consortium (W3C) o especificaciones de APIs RESTful.
Para un arquitecto de sistemas, RFC 2119 es fundamental porque proporciona un marco para la comunicación precisa de requisitos en el diseño y la implementación de sistemas distribuidos y protocolos. Entender estas palabras clave permite evaluar la robustez, interoperabilidad y conformidad de una implementación con un estándar. Al diseñar un sistema, el arquitecto debe decidir qué requisitos son 'MUST' (críticos para la funcionalidad básica), 'SHOULD' (importantes para la interoperabilidad o el rendimiento óptimo) o 'MAY' (opcionales, ofreciendo flexibilidad). Ignorar estas distinciones puede llevar a sistemas no conformes, problemas de interoperabilidad, o a una sobre-ingeniería innecesaria. Además, al redactar especificaciones internas o contratos técnicos, adoptar esta terminología puede mejorar significativamente la claridad y reducir malentendidos entre equipos de desarrollo, operaciones y negocio.