Resumen

  • RFC 2987 sometió charset y language a comparaciones exactas e insensibles a mayúsculas, aunque uno expresaba normalmente capacidad y el otro preferencia.
  • Los nombres principales de juegos de caracteres y las etiquetas lingüísticas comparadas como tokens completos reducían desacuerdos sin demostrar decodificación ni comprensión.
  • Los pesos de calidad ordenaban alternativas dentro de una política local; no probaban que la variante elegida existiera, se representara bien o sirviera al usuario.

Dos registros y una diferencia decisiva

Publicada en noviembre de 2000 como Proposed Standard, RFC 2987 dedicó casi todo su espacio a dos formularios. El primero dio a charset el identificador 1.3.6.1.8.1.31. El segundo asignó a language el 1.3.6.1.8.1.32. IANA conserva las entradas 31 y 32 en el árbol IETF de características de medios.

La arquitectura venía de RFC 2506: un espacio de nombres independiente del protocolo para declarar capacidades o preferencias de presentación. RFC 2533 ofrecía la sintaxis para combinar predicados y asociarles valores q. Así, varias aplicaciones podían reutilizar una expresión sin inventar vocabularios incompatibles.

Ambos registros parecían gemelos. Los valores eran tokens registrados. Sólo se comparaban por igualdad. La comparación ignoraba mayúsculas y minúsculas. Los ejemplos formaban una disyunción ponderada.

Pero RFC 2987 no dejó que la forma decidiera el significado.

Para la mayoría de los dispositivos, charset era normalmente una capacidad: un equipo no puede procesar inteligentemente texto en una codificación que desconoce. language, en cambio, era normalmente una preferencia, no un requisito. En el uso imaginado, mostrar un idioma significaría muchas veces pronunciarlo mediante una computadora. Aun así, preferir una lengua no equivale a carecer de hardware o software para cualquier otra.

La misma máquina de comparación recibía dos clases de afirmación.

La codificación establece una condición de ejecución

El ejemplo de charset asigna 1,0 a utf-8, 0,9 a iso-8859-1 y 0,5 a utf-16. Ese orden sólo es útil si la capacidad anunciada existe en el sistema que va a actuar.

La coincidencia de una etiqueta no convierte bytes en caracteres. Primero, el nombre debe describir los bytes reales. Después, un decodificador tiene que aceptar la secuencia y producir los caracteres adecuados. La fuente y el motor de presentación deben disponer de glifos. Por último, una persona debe poder leerlos. Cada paso puede fracasar mientras el predicado inicial sigue siendo sintácticamente verdadero.

RFC 2913 había separado la característica type de charset. Un dispositivo podía manejar text/plain sin manejar todas las codificaciones posibles de texto plano. El tipo de representación y la transformación de octetos a caracteres eran evidencias relacionadas, no intercambiables.

También había una dificultad de nombres. RFC 2978 permitía varios nombres para un juego de caracteres, pero exigía uno principal y evitaba que un mismo nombre designara dos juegos distintos. RFC 2987 recomendaba no usar alias porque las herramientas podían convertirlos al nombre principal al manipular una expresión.

Escribir el nombre principal en minúsculas disminuía las diferencias accidentales. No verificaba la tabla de conversión ni la corrección del código. La canonicalización resolvía una disputa léxica, no toda la ruta de ejecución.

La RFC añadió que charset debía acompañar cualquier capacidad para tratar datos textuales. La palabra «texto» no bastaba si el receptor ignoraba qué regla debía aplicar a los bytes.

La lengua organiza una elección humana

La segunda expresión ordenaba no-nynorsk, no-bokmaal e i-sami-no. La igualdad seguía siendo exacta, pero su fallo tenía otro significado.

RFC 1766 construía etiquetas lingüísticas con una parte principal y subetiquetas. Sin embargo, exigía tratar la etiqueta completa como un token. Las subetiquetas eran administrativas; no formaban por sí solas un árbol de inteligibilidad. Compartir un prefijo no demostraba que dos hablantes se entendieran.

RFC 2987 preservó esa cautela. No se comparaban subetiquetas. No importaba la caja tipográfica. Una coincidencia nombraba una opción registrada, pero no medía alfabetización, dialecto, pronunciación, accesibilidad o comprensión.

Al mismo tiempo, una desigualdad no tenía por qué cerrar el servicio. El usuario podía aceptar una segunda lengua antes que recibir silencio. O podía considerar inútil cualquier alternativa. Esa política debía estar en el perfil y en la aplicación, junto con las variantes realmente disponibles.

Convertir toda preferencia en veto técnico niega posibilidades. Convertir toda preferencia en sugerencia prescindible ignora al usuario. La sintaxis compartida no resuelve por sí sola esa tensión.

Un valor de calidad no es una medición de calidad

El nombre puede confundir. En RFC 2533, una calidad califica un predicado; si falta, vale 1. El documento no impone una fórmula universal para combinar preferencias. Un q alto no es una prueba obtenida después de la presentación. Es una entrada antes de decidir.

Por eso q=1.0 no asegura que el perfil esté actualizado, que exista contenido en esa lengua, que el motor de voz pronuncie bien, que la etiqueta coincida con los bytes o que el usuario consiga su objetivo. Ni siquiera demuestra que dos evaluadores elegirán lo mismo si tienen políticas o conjuntos de candidatos diferentes.

Una operación explicable conserva el conjunto recibido, la normalización, la versión de la regla, los candidatos, la alternativa elegida, el recurso de ejecución y el resultado. «Negociación correcta» no puede sustituir a todos esos recibos.

Coordinación sin evaluador soberano

El registro IANA permite que implementaciones independientes hablen de las mismas características. Esa es una función real y duradera. No convierte a IANA, al IETF ni al autor del perfil en árbitro de la selección concreta.

Quien produce el perfil controla la declaración. Quien publica las representaciones controla la oferta. El software receptor controla normalización, comparación, pesos y respaldo. El usuario soporta la consecuencia. Ninguna capa puede atribuirse la autoridad de las demás.

La idea de especificación inicial mínima de Lu Heng ayuda a leer este diseño. El sistema común fija nombres y semántica de comparación suficientes para interoperar. Las decisiones posteriores permanecen localizadas. Un evaluador puede adoptar un respaldo distinto sin pedir permiso a una autoridad central, siempre que no lo presente como si la norma lo hubiera decidido.

La primacía del código en funcionamiento añade una prueba incómoda: una entrada registrada no demuestra una implementación instalada. El hecho operativo es lo que el dispositivo comparó, seleccionó, decodificó y presentó.

Las capas de realidad son: registro, expresión, normalización, evaluación, selección, capacidad, ejecución, percepción y resultado. Un token válido no prueba toda la cadena. Una elección válida no prueba que la persona entendió.

La advertencia de seguridad

Cada formulario incluyó la misma reserva. Si se conoce un fallo de seguridad al mostrar determinado juego de caracteres o idioma en un entorno, saber que el dispositivo lo acepta podría ayudar ligeramente a un atacante. RFC 2987 no identificó productos, vulnerabilidades ni incidentes concretos.

La observación sí revela que las capacidades anunciadas son datos operativos. Dirigen decisiones y pueden exponer superficie. Un sistema prudente divulga lo necesario, mantiene actualizado el perfil y no toma «aceptado» como sinónimo de «seguro».

La historia de RFC 2987 no consiste en dos nuevas palabras. Consiste en mantener una diferencia cuando la abstracción invitaba a perderla.

Una etiqueta solía responder: «¿puede la máquina procesarlo?». La otra: «¿qué preferiría la persona?». Ambas podían usar igualdad y pesos. Sólo eran interoperables si el evaluador recordaba qué clase de respuesta estaba leyendo.

Fuentes