Resumen

  • RFC 822, de agosto de 1982, separó los campos de correo formalmente publicados de los definidos por usuarios. Los primeros nunca empezarían por X-; los segundos ganaban un espacio de nombres protegido.
  • La protección tuvo un coste cuando hubo que cambiar de nombre. RFC 2068, de enero de 1997, pidió tratar x-gzip y x-compress como equivalentes de gzip y compress. RFC 5064, de diciembre de 2007, estandarizó Archived-At pero también describió y registró su precursor X-Archived-At.
  • RFC 6648, de junio de 2012, desaconsejó X- en los nuevos parámetros textuales de protocolos de aplicación. El nombre no debía servir para adivinar estatus normativo ni seguridad; los registros y sus procedimientos debían hacerlo explícito.

El territorio reservado a lo provisional

Un campo de mensaje combina nombre y valor. El programa receptor usa el nombre para decidir cómo interpreta lo demás. Si dos grupos dan sentidos distintos a un mismo nombre, chocarán al intercambiar mensajes. Reservar una familia de nombres para pruebas locales parecía una solución limpia: nadie debía pedir permiso para experimentar, pero el inventario oficial conservaría sitio para futuras extensiones compartidas.

Eso hizo RFC 822 en agosto de 1982. Distinguió los campos que podrían publicarse como extensiones formales de aquellos que un usuario definía por su cuenta. Los formales nunca llevarían X- al principio. La letra daba a los campos privados un conjunto protegido de nombres. El laboratorio podía enviar información adicional sin esperar a que una institución la reconociera.

La protección llevaba una cláusula oculta. Para un lector humano, X- comunicaba una situación social: privado o experimental. Para el programa, las dos letras eran parte inseparable del identificador. Si una aplicación esperaba X-Ejemplo, no aprendería a leer Ejemplo por el hecho de que un comité publicara ese segundo nombre. Graduar el experimento obligaba a mover también a quienes ya lo usaban.

Antes de desplegar nada, renombrar cuesta poco. Después de que las aplicaciones hayan escrito y leído millones de mensajes, el viejo nombre puede seguir apareciendo en archivos, puertas de enlace y código. El nombre oficial se añade; el provisional no se evapora.

HTTP paga por dos nombres

RFC 2068, publicado en enero de 1997, deja una huella precisa. Al explicar las codificaciones de contenido HTTP, indicó que, por compatibilidad con implementaciones anteriores, las aplicaciones debían considerar x-gzip equivalente a gzip y x-compress equivalente a compress. La norma no pudo elegir una forma pulcra y descartar la otra. El tráfico anterior obligó a escribir una regla para ambas.

La consecuencia toca al procesamiento, no a la estética. Un emisor puede anunciar el contenido con cualquiera de esos nombres. Un receptor que reconozca uno solo puede tratar mal el cuerpo recibido. Un intermediario necesita conservar la relación correcta al reenviar o archivar. La etiqueta experimental acabó incorporada a la descripción formal de qué debe entender el software.

El correo ofrece otra escena. RFC 2822, en abril de 2001, sustituyó a RFC 822 y describió campos opcionales sin mantener la antigua división gramatical entre extensiones oficiales y campos de usuario. El cambio en la regla no reescribió los mensajes antiguos. Una etiqueta impresa en los datos seguía siendo un dato.

En RFC 5064, diciembre de 2007, apareció Archived-At: un campo con la dirección de una copia archivada del mensaje. La especificación también tuvo que incluir el precursor X-Archived-At para compatibilidad. Permitió analizar el campo antiguo, pero aconsejó dejar de generarlo. Registró el viejo nombre con estado obsoleto junto al nuevo. La ceremonia de estandarización acabó con dos asientos en el registro.

Hay una distinción útil entre los ejemplos. Para las codificaciones HTTP, el estándar estableció equivalencia entre pares concretos. Para el campo del archivo, recomendó aceptar la entrada antigua y producir la nueva. Ningún texto ofrece una cifra de usuarios o mensajes para cada variante. Harían falta inventarios de versiones o muestras fechadas para medirla. La obligación de leer dos formas, en cambio, consta en las normas originales.

Una letra deja de conceder autoridad

RFC 6648, publicado en junio de 2012 como práctica recomendada del IETF, describió el defecto de diseño. Un parámetro no estandarizado puede extenderse ampliamente. Al formalizarlo bajo otro nombre, unas implementaciones saben leer solo el antiguo y otras solo el nuevo. Para evitar la ruptura, las nuevas suelen conservar el nombre con X- durante años. El supuesto espacio experimental se convierte en un estándar de hecho que ocupa sitio junto al estándar escrito.

La nueva recomendación se aplica a parámetros textuales recién definidos en protocolos de aplicación. Los creadores no deberían añadir X- por sistema. Los responsables de campos ya existentes decidirán si los mantienen o migran. El documento no prohíbe extensiones privadas, ni borra automáticamente las reglas particulares de otros protocolos. Retira una convención de nombres que confundía el estado de una idea con su identidad en el cable.

Para los programas lectores fijó un límite aún más claro: no deben deducir el estado normativo de un parámetro solo por tener o no tener X-. Tampoco deben considerar seguro el nombre sin prefijo e inseguro el otro por esa grafía. El nombre identifica un campo; no es un certificado de revisión ni una evaluación de riesgo.

Los diseñadores, proponía RFC 6648, debían ofrecer registros amplios y procedimientos sencillos de inscripción, con registros provisionales y permanentes cuando sirvieran. Los nombres con X- podían registrarse; la presencia del prefijo no debía dictar su rango. Una institución puede actualizar en un registro el estado de un nombre sin obligar a todos los programas a aprender una segunda forma.

La revisión formal también puede cambiar el significado de una extensión. Una versión estandarizada podría tener propiedades de seguridad distintas de su antecesora. Por eso sería peligroso suponer que eliminar X- equivale siempre a obtener la misma función. RFC 2068 establece una equivalencia concreta para sus dos codificaciones; no concede una licencia universal para borrar el prefijo en cualquier protocolo.

El experimento que triunfa deja herencia

La división de 1982 ofrecía libertad a quienes querían probar algo nuevo. El examen de 2012 observó lo que ocurre después del éxito: mensajes guardados y software instalado dan valor al nombre previo. La autoridad que publica el nuevo puede registrar la decisión, pero no puede hacer que todos los receptores olviden de golpe el antiguo.

Los documentos muestran el coste sin necesidad de inventar estadísticas. En 1997, HTTP cargó con dos nombres para una codificación. En 2007, el correo registró una forma vieja obsoleta junto a su sustituta. Para saber cuántos programas usaron cada una en una fecha concreta habría que revisar implementaciones o trazas fechadas. Para saber por qué cambió la recomendación, basta ver cómo el cajón reservado a pruebas acabó formando parte del mobiliario permanente.

RFC 6648 no vació ese cajón. Pidió que las próximas ideas pudieran entrar en un registro sin nacer con una deuda de renombramiento. El estado de la idea podía cambiar; su nombre en la red no tenía por qué cambiar con él.