Resumen

  • RFC 1766 hacía visibles los segmentos de una etiqueta, pero indicaba que la aplicación debía manejar el valor completo como un único token; las subetiquetas ordenaban un registro, no componían un menú.
  • Los códigos ISO, los registros de IANA y el espacio privado ocupaban partes distintas del formato. La especificación que usara la etiqueta debía definir cómo se relacionaba con el objeto informativo.
  • Las revisiones posteriores añadieron operaciones de correspondencia expresas. No convirtieron cada guion de la gramática de 1995 en un camino de navegación.

El guion parecía una ruta de migas

En marzo de 1995, RFC 1766 propuso una forma compacta de indicar el idioma de un objeto informativo. La sintaxis podía sugerir un árbol: una etiqueta principal, seguida de fragmentos opcionales separados por guiones. en-US resultaba familiar; az-arabic y az-cyrillic empezaban igual. El documento puso un límite claro a esa lectura: las aplicaciones debían tratar la etiqueta entera como un solo token. La división entre etiqueta principal y subetiquetas era un mecanismo administrativo, no una ayuda de navegación.

La aclaración importa porque una cadena legible no equivale a una jerarquía de órdenes. La etiqueta principal admitía de una a ocho letras, y cada subetiqueta tenía el mismo límite. No se permitían espacios dentro de la cadena. La mayúscula o minúscula tampoco cambiaba el valor. Las convenciones podían poner los códigos de país en mayúscula y los de idioma en minúscula, pero RFC 1766 decía que esa práctica no añadía significado.

El espacio de nombres sí tenía límites. Las etiquetas principales de dos letras seguían ISO 639. i se reservaba para registros definidos por IANA; x abría el uso privado, cuyas subetiquetas IANA no registraría. Las demás etiquetas principales quedaban reservadas hasta que una revisión de la norma las asignara. En la primera subetiqueta, los códigos de dos letras seguían ISO 3166 alpha-2; los valores de tres a ocho letras podían registrarse con IANA. También podían registrarse subetiquetas posteriores.

La estructura cumplía dos funciones fáciles de confundir: permitía leer la cadena por partes y ofrecía una forma de administrar el espacio de nombres. No decía que hubiera que recorrer esas partes como directorios. Tampoco asignaba a cada segmento un sentido universal para todas las aplicaciones. RFC 1766 dejaba a la norma del contexto la tarea de definir la relación entre etiqueta y objeto informativo.

El registro daba constancia pública de cada valor

Los ejemplos de RFC 1766 abarcaban la identificación de país (en-US), dialectos o variantes (no-nynorsk, en-cockney), un idioma registrado por IANA (i-cherokee) y variantes de escritura (az-arabic, az-cyrillic). El documento añadía una salvedad importante: ninguna de las subetiquetas de ejemplo estaba asignada entonces. Eran demostraciones de sintaxis, no un catálogo de valores disponibles.

Para proponer un valor fuera de las asignaciones ISO predefinidas, la persona solicitante completaba un formulario con el nombre del idioma, su nombre nativo, una descripción publicada y otros datos. La solicitud circulaba dos semanas en una lista abierta. Un revisor designado por el director del área de Aplicaciones del IETF podía enviarla a IANA o rechazarla si recibía objeciones de peso; la decisión podía apelarse ante el IESG. La grafía compartida pasaba a ser verificable por medio de un registro público, no por el mero hecho de añadir otro sufijo después de un guion.

El mecanismo también era acotado: registraba identificadores y referencias, no una interfaz universal. Una etiqueta no decía a cada protocolo si debía elegir una representación, filtrar una biblioteca, abrir una ruta o mostrar un selector de idioma. Ese comportamiento dependía del contexto en que se usara.

Un encabezado podía enumerar idiomas sin definir el selector

RFC 1766 también definió Content-Language, un encabezado que podía enumerar varias etiquetas completas. Para multipart/alternative de MIME, incorporó el parámetro Differences con el que se podía indicar que las partes diferían por idioma. El documento explicó por qué un lector podía aprovechar esa información, pero dejó fuera de su alcance el mecanismo que elegiría qué parte mostrar.

Así quedaron separadas tres preguntas: qué cadena identifica el idioma de un objeto, qué elemento del protocolo transporta esa cadena y qué hace con ella la aplicación receptora. Una etiqueta podía aparecer en un encabezado de contenido; un contenedor podía señalar alternativas lingüísticas; cada lector aún necesitaba su propia lógica de selección. La RFC aportaba una etiqueta común y un punto de conexión, no una navegación universal.

La evolución posterior aclara la diferencia. RFC 3066, publicada en 2001, permitió dígitos en las subetiquetas e introdujo language-range. Un rango podía coincidir con una etiqueta completa o con un prefijo que terminara justo antes de un guion. Era una operación de correspondencia definida. RFC 3282 especificó después los encabezados Content-Language y Accept-Language, con rangos de preferencia y valores de calidad opcionales. Esos cambios incorporaron reglas explícitas alrededor de las etiquetas; no transformaron el guion original en una ruta general.

RFC 4646, en 2006, y RFC 5646, en 2009, continuaron la revisión de BCP 47. La cronología muestra que la gramática y el registro cambiaron. No demuestra que todos los clientes procesaran correctamente cada valor ni que una etiqueta eligiera por sí sola una página, una traducción o una forma de renderizado. La lección histórica de RFC 1766 es más precisa: un identificador estructurado puede seguir siendo un valor indivisible para la aplicación mientras sus segmentos sirven a convenciones administrativas.

Fuentes y alcance

La especificación es RFC 1766. La revisión posterior aparece en RFC 3066, RFC 3282, RFC 4646 y RFC 5646. Estos textos documentan la gramática, el registro y los cambios de protocolo; no prueban una implementación ni un despliegue universales.