Resumen

  • RFC 2277 obligó a las especificaciones a distinguir texto y protocolo, identificar el charset, admitir UTF-8 y ofrecer una forma definida de transportar información lingüística.
  • Cumplir esas reglas documentaba una decisión de normalización; no demostraba soporte del receptor, aceptación de la negociación, convenciones locales, representación correcta ni comprensión.

RFC 2277 apareció en enero de 1998 como BCP 18. Su destinatario inmediato no era un lector final, sino la especificación que pretendía avanzar por el proceso de estándares del IETF. El anuncio del IESG fue directo: los protocolos con texto debían poder usar UTF-8 y llevar etiquetas de lengua; una excepción necesitaba una variación aprobada.

Esa política cerró una salida fácil. Un grupo de trabajo ya no debía escribir “otra capa se ocupa” sin identificar al responsable. Tenía que señalar qué elementos eran comandos o identificadores del protocolo y cuáles eran texto para personas. También debía decir si los nombres admitían internacionalización o permanecían en US-ASCII. La norma obtenía así una superficie de revisión común.

Una superficie de revisión no es una prueba de ejecución. El charset de RFC 2277 nombra las reglas que convierten octetos en caracteres. La etiqueta responde qué decodificación se debe intentar. No confirma que los octetos sean válidos, que el programa receptor implemente esa decodificación, que haya glifos disponibles ni que el resultado visual conserve la intención.

La obligación de admitir UTF-8 tampoco borró el pasado. Los protocolos existentes y los almacenes heredados podían necesitar otros valores predeterminados; se permitían charsets adicionales registrados. Por eso la política exigía una capacidad común sin fingir que toda instalación ya la poseía. Incluso la negociación de charset era una decisión duradera: en una sesión interactiva podía acordarse una representación, mientras que en correo o datos almacenados solo quedaba unir una declaración clara al contenido.

La lengua añadía otra dimensión. RFC 2277 exigía un medio para transportar información lingüística, no una etiqueta presente en cada mensaje. Recomendaba RFC 1766 y diferenciaba lengua de locale POSIX. La primera identifica una lengua humana; la segunda puede abarcar ordenación, fechas, moneda y otras convenciones. Un receptor puede aceptar o ignorar la opinión del emisor sobre esas reglas.

HTTP mostraba por qué una preferencia no equivale a conocimiento. RFC 2068 definía Accept-Language para expresar preferencias y avisaba que la inteligibilidad depende de cada usuario. La coincidencia por prefijo facilitaba la selección, pero no implicaba que quien entiende una etiqueta comprenda todas sus variantes. Accept-Charset señalaba representaciones aceptables; tampoco convertía una respuesta en evidencia de que el texto se mostró bien.

RFC 1766 mantenía un límite semejante: la etiqueta de lengua no bastaba para elegir el renderizado correcto de un charset en todos los casos, especialmente en texto mixto japonés y chino. La información ayuda a buscar, segmentar, sintetizar voz o seleccionar variantes. No reemplaza fuentes, reglas bidireccionales, disposición, vocabulario ni juicio humano.

RFC 2277 pidió que las decisiones se reunieran en una sección de “Internationalization Considerations” junto a las consideraciones de seguridad. Esa sección funciona como recibo de diseño: permite localizar elecciones y responsabilidades. No demuestra que el código, el contenido traducido y la operación sigan el contrato. El propio RFC observó que una advertencia de seguridad en una lengua extranjera puede provocar una conducta inapropiada y que las versiones multilingües pueden ser incoherentes.

Su lección histórica no es que una etiqueta resolviera la comunicación. Es que las decisiones de texto debían quedar expuestas antes de aprobar una especificación. Después, cada transición —declaración, capacidad, selección, decodificación, presentación y comprensión— seguía necesitando evidencia propia.

Fuentes y límites

Estas fuentes prueban la política y los mecanismos históricos. No prueban despliegue actual, comportamiento de un producto, una transacción concreta ni el entendimiento de una persona.